TweetFollow Us on Twitter

How To Design An Object-Based Application

How To Design An Object-Based Application

BRIAN WILKERSON

The object-based approach promises to make software easier to reuse, refine, test, maintain, and extend. But simply implementing an application in an object-based language does not guarantee these benefits. They can only be achieved if the implementation is based on a sound object-based design. This article presents a process for creating such a design.

As every programmer knows, software applications are becoming increasingly complex, and as a result, increasingly expensive to build and maintain. The good news is that if you are willing to spend the time to carefully develop an object-based design for your software, implementation can proceed smoothly and quickly, and the resulting software will be relatively easy to reuse, refine, test, maintain, and extend. This article gives an overview of the object-based approach and then describes step by step a two-phase process for designing an object-based application.

BASIC CONCEPTS OF THE OBJECT-BASED APPROACH

Programmers familiar with non-object-based languages are used to dividing information into two distinct kinds: functions and data. Procedural programming, based on this division of information, focuses on how to accomplish the goals of the program. It begins by identifying the high-level tasks that need to be performed, and then decomposing each task into smaller tasks until the level of the language statement is reached. Procedural programming concerns itself almost immediately with the implementation of the program: the steps that compose each function, and the particulars of the data to be operated upon.

By contrast, the focus of the object-based approach is more abstract. It asks first about the intention of the program: asking what, not how. It views the programming process as one of modeling the world. It begins by identifying the things inhabiting the part of the world being modeled, and the behavior of those things, both as individuals and with respect to the other things in the world.

The object-based approach uses abstraction to manage the complexity inherent in real-world problems. An abstraction is a simplified picture of the world, arrived at by generalizing about details. The object-based approach relies on abstraction mechanisms such as encapsulation, information hiding, polymorphism, and inheritance.

ENCAPSULATION
Encapsulation is the enclosing of a number of separate related things within a single physical or conceptual capsule. For example, a telephone number encapsulates individual digits at a higher, abstract level at which the numbers form a single entity. When you think of your telephone number, you don't think of it as seven separate digits. You think of it as a single unit that happens, almost incidentally, to be composed of seven digits.

INFORMATION HIDING
Encapsulation makes complexity more manageable, but it doesn't reduce the amount of visible detail. Information hiding takes encapsulation a step further, reducing complexity by hiding some or all of the things that have been encapsulated. For example, when you use a compact disc player, you don't generally think of all the electrical and mechanical components within it. You don't need to know how it works. What's important is what it does: it plays the music you want to hear.

OBJECTS
An object is an encapsulation of data and the functions that manipulate that data. But more than that, an object hides the data and possibly some of the functions, revealing only those functions that need to be made available to other objects. The set of visible functions defined by an object is referred to as the behavior of the object.

The data and functions that are hidden within an object define the implementation of that object. That is, they definehow that object does what it does. The behavior of an object defineswhat the object does. In keeping with the abstract nature of the object-based approach, object-based design focuses exclusively on the behavior of objects. The object-based approach views a program as a collection of objects that interact with other objects to accomplish the goals of the program. Objects interact with other objects by sending those objects messages requesting that a publicly visible function be executed. A message specifies the name of the function being requested and the arguments required by the receiver of the message to execute the function.

POLYMORPHISM
Polymorphism is an abstraction mechanism by which two or more different kinds of objects can respond to the same message, each in its own way. This means that an object can send a message to another without knowing how the receiver will respond, or what other messages the receiver might also understand. The sending object just needs to know that many different kinds of objects can be defined to respond to the message being sent and that the receiver is one of those.

CLASSES
A class is a specification of the behavior of an arbitrary number of similar objects. Objects that share the same behavior are said to belong to the same class. The objects that belong to a class are referred to as instances of that class. The process of dynamically creating objects is known as instantiating a class.

Classes are another abstraction mechanism. They allow us to focus on the kinds of objects in an application rather than on the individual objects.

Throughout the remainder of this article, when we refer to some aspect of a class, we mean the definition of that aspect of the instances of the class. For example, when we refer to the behavior of a class, we mean the definition of the behavior of the instances of that class. The meaning should be clear from context.

INHERITANCE
Inheritance is an abstraction mechanism by which new classes can be derived from existing ones, thereby "inheriting" both data and functions. The inheritor (called a subclass) reuses the code that it inherits from its superclass. Again, in the design phase, we are only interested in the inheritance of behavior.

THE CLIENT-SERVER MODEL
The model we use for our object-based design views the world as a system of objects collaborating to perform the work required of them: the client-server model.

The client-server model is a description of the interaction between two entities: the client and the server. A client makes requests of the server to perform services. A server provides a set of services upon request.

The ways in which the client can interact with the server are described by a contract: a description of the requests that can be made of the server by the client. Both must fulfill the contract: the client by making only those requests it specifies, and the server by correctly responding to those requests.

In an object-based design, both client and server are objects. Any object can act as either a client or a server at any given time. The design focuses on the contract between clients and servers by asking (1) what actions each object is responsible for, and (2) what information each object shares.

THE BENEFITS OF OBJECT-BASED DESIGN

If you spend a meaningful amount of time on carefully developing an object-based design for your software, implementation can proceed more smoothly and quickly than it would for a traditional procedural program. The resulting software can also be easier to test, maintain, refine, and extend.

An object-based design can improve implementation by encapsulating pieces of the program into components that can be implemented without considering the interactions with the rest of the system. If an interface between components then seems wrong for some reason, the system can be changed at just that one point; other parts of the system are not affected.

A careful design can also make it easier to test the application. Classes can be isolated and tested one at a time. An error can more easily be traced to a specific class. Classes can be shown to function before being plugged into the rest of the system.

Similarly, the rigorous specification of the interfaces between classes allows testers to more easily spot discrepancies between the output of one component and the input required toanother. Such a careful specification of the interfaces requires a complete understanding of the responsibilities of each component. Holes in the system--places where a responsibility was omitted by the specification, or stated ambiguously, or made part of the wrong class--can more easily be spotted and filled.

After the application has been implemented, it's also easier to maintain. Encapsulation and information hiding rigidly constrain the patterns of communication within the application, so that they can be understood more easily. This makes it easier to determine where a problem lies and where any ramifications may appear after you fix the problem. In this way, you can guard against the notorious problem of one bug fix introducing other bugs.

A system that can be understood can also be refined and extended. If the interfaces between classes have been rigorously controlled, new portions of the system can be created to use the same interfaces, but to do different things with them. You can also add new classes that respond to old requests in ways appropriate to the new system of which they are now a part. Functionality can thereby be increased at far less cost.

In sum, object-based design enables us to build classes that can be depended upon to behave in certain ways, and to know what state results from that behavior. Such classes can be reused in every application that can make use of this behavior and knowledge. With careful thought, you can construct classes that will be useful to many applications.

A TWO-PHASE PROCESS FOR DESIGNING AN APPLICATION

The remainder of this article describes a process for creating object-based designs. The result of this process, an object-based design, consists of a structure of classes modeling the problem, a description of the public behavior of those classes--their responsibilities, and a description of the patterns of communication among the classes.

The design process we use has two phases:

  1. An initial exploration of the possibilities, which produces a preliminary design.
  2. A rigorous analysis of the preliminary design.

Both of these phases play critical roles in the object-based design process.

The exploratory phase of object-based design concentrates on identifying the classes, assigning responsibilities to those classes, and determining which other classes collaborate with them to fulfill those responsibilities. At this stage of the engineering process, very little effort has been invested in any specific design. It is therefore relatively cheap to play with the possibilities, trying out various ways to configure your system. A little time spent exploring at this point can lead to a lot of time and effort saved later, as it will be easier to reuse parts of the design, or to refine and extend it.

The results of exploration, however, must be carefully pruned and edited. No one can count on getting it right the first time. The preliminary design must be critically examined, to maximize both encapsulation and inheritance. Only in this way can the use of object-based design fulfill its promise of producing software that is easy to reuse, refine, test, maintain, and extend.

To illustrate the design process described here, we'll use the example of a spreadsheet program, the specification for which appears in the sidebar. This example is too simple to be a true application, but for the purposes of this article it will give you a feeling for how to use the design process. THE EXPLORATORY PHASE
The exploratory phase of object-based design consists of three steps:

  1. Finding the classes.
  2. Assigning responsibilities to them.
  3. Determining the collaborations required to fulfill those responsibilities.

Let's look at each of these steps individually.

FINDING CLASSES
Choosing the classes of objects that make up your application is a key part of modeling it. The classes should define the essence of your application; they should emphasize the important aspects, and discard irrelevancies.

Generate candidate classes. When you start your design, you frequently have nothing more than a specification outlining the functionality envisioned for the system as a whole. If that's all you have, that's what you start with. Begin by reading the specification until you are familiar with it. Now reread the specification, taking note of every noun or noun phrase in the document. These are your candidate classes.

The following list results from doing this with the spreadsheet specification:

spreadsheet programdecimal pointformula
applicationmonetary formatexpression
userdollar signsimple expression
electronic spreadsheetreal formatadditive operator
new spreadsheetscientific formatterm
existing spreadsheetzeromultiplicative operator
filesonefactor
spreadsheetexponentconstant
celltext cellcell name
rowarbitrary textnumber
columnfirst characterargument
nameequal signcomma operator
ordinal positiontexttextual representation
valueleft-aligned texttype
numeric cellcentered textrectangular group of cells
numeric valueright-aligned textindividual cell
formatjustified textentire spreadsheet
integer formatexpression cellselected cell

Choose classes from candidates. Once you have a list of possible classes, you must decide which of them will become part of the model you are designing. The following guidelines are useful in choosing which noun phrases represent classes and which are spurious.

  • Model physical objects, such as windows on the display or printers on the network. The cells of a spreadsheet can be thought of in this way, so we tentatively create the class Cell.
  • If more than one word is used for the same concept, choose the one that is most meaningful in terms of the rest of the system.

    For example, "application" really means "the spreadsheet program" in this context. The phrase that best describes the meaning is kept, while the rest are discarded. In some cases, none of the phases is appropriate, so a new one must be created.

    Our list is full of such synonyms and naming problems. Following is a list of the words with synonyms. The words that remain candidates are followed by the synonyms we have rejected, indented below them.

    spreadsheet electronic spreadsheet new spreadsheet existing spreadsheet entire spreadsheet cell numeric cell text cell expression cell name cell name value numeric value text arbitrary text textual representation cell group rectangular group of cells individual cell selected cells

    In addition, one more naming problem exists. Rows and columns are just rectangular groups of cells. The general concept capturing this commonality is "cell group."

  • Be wary of adjective-noun phrases. An adjective-noun combination can mean a dif- ferent kind of object, a different use of the same object, or it could be utterly irrelevant. Ask if the object represented by the noun behaves differently when the adjective is applied to it. If the use of the adjective signals that the behavior of the object is different, then make a new class.
  • Model categories of objects. Such categories represent abstract superclasses, and should therefore be modeled. "Expression" and "value" are examples of abstract superclasses; there are several different kinds of each in the spreadsheet.
  • Model known interfaces to the outside world, such as physical devices, a window- ing system, or the operating system, as fully as your initial understanding allows. The interface to the outside world in this case is represented by the noun "file," which becomes a candidate class Don't model things outside the application. Our list includes a variety of things obviously outside the bounds of the system, such as "user," "first character," and "type."
  • Model the values of attributes of objects, but not the attributes themselves. For example, each cell has a name. The name is an attribute whose value is a string of characters. Therefore, the class String should be created, but there will be no class called Name; it will be an attribute of the class Cell. The following table contains the phrases representing attributes, the class(es) of objects having that attribute, and the class(es) of the value of the attribute.

[IMAGE Object_Oriented_v004_htm1.GIF]

How should formats be represented? The format controls the way in which the value is displayed. This kind of control is usually handled by either sending different messages to a class, or sending the same message to different classes. The former is preferred in this case because the format can change independent of the value. The format, therefore, should be the message with which the value is displayed (or an encoding of it if the target language does not support messages as objects). We can therefore discard all of the noun phrases representing types of formats, which were the following:

integer formatscientific formatright-aligned text
monetary formatleft-aligned textexpression
real formatcentered textjustified text

We replace the phrases describing the syntactic representation of expressions, given below, with classes representing the semantic structure of expressions.

formulasimple expressionmultiplicative operator
expressionadditive operatorfactor
comma operatortermconstant

Record classes. When you have identified the first, tentative list of classes, they need to be recorded. For each class, take a 4" x 6" index card, and write the class name at the top of the card. You should use index cards to record classes because they are compact, easy to manipulate, and easy to modify or discard. Each index card will eventually contain the kinds of information indicated in Figure 1.

[IMAGE Object_Oriented_v004_htm2.GIF]

Figure 1. Contents of Each Index Card

Some classes will be missing and others will be eliminated later, but don't worry. Your design will go through many stages on its way to completion, and you will have ample opportunity to revise.The final list of candidate classes is as follows:

Binary ExpressionComputed ValueSpreadsheet
CellConstant ExpressionTextual Value
Cell GroupExpressionValue
Cell ReferenceFile
ExpressionNumeric Value

ASSIGNING RESPONSIBILITIES
You have now found the classes in your system. Next you must decide what behavior each of them is going to be responsible for.

Responsibilities include two key items:

  • the information other classes can ask for from a class
  • the actions a class can perform

Responsibilities are meant to convey a sense of the purpose of a class and its place in the system. As you seek to identify responsibilities, use the conceptual model of the client-server contract. The contract between two classes represents the list of services one class can request of another. A service can be either the performance of some action or the return of some information. If an object provides a service, that is one of its responsibilities. All of the services listed in a particular contract are the responsibilities of the server for that contract.

Find responsibilities. To find responsibilities, return to the specification. This time, take note of all the verbs. Use your judgment to determine if each represents an action that some class within the system must perform. Also use the work you just performed when you identified classes. The fact that you identified a class indicates that you saw a need for it to fulfill at least one responsibility. The name you chose for that class probably suggests that responsibility, and possibly others. From the specification, we can derive the following candidate responsibilities:

open from a filecolumns have cellsremove columns
save to a filespecify cell formatinsert rows
maintain a collection of cellsnumbers convert to textinsert columns
cell have namesusers select rectangularremove values of cells
groups of cells
cell have valuescut selected cellsreplace values of cells
rows have namescopy selected cellsedit values of cells
rows have cellspaste cellsrecompute values of cells
columns have namesremove rows


Assign responsibilities to classes. Once you have listed a number of candidate responsibilities for the classes in your application, you can go about assigning each responsibility to the appropriate class. The following guidelines can prove useful as you seek to apportion the responsibilities to each class.

  • Distribute system intelligence as evenly as possible. A system can be thought of as having a certain amount of intelligence, such intelligence being what the system knows and what actions it can perform. Within any system, some classes of objects can be viewed as being relatively "smart," while others seem less so. Distributing the intelligence embodied within your system among a variety of classes allows each class to know about relatively fewer things, thus producing a more flexible system, and one that is easier to modify.
  • Keep behavior with related information, if any. If a class is responsible for knowing certain information, it is logical also to assign it the responsibility of performing any operations necessary upon that information. Conversely, if a class requires cer- tain information in order to perform some operation for which it is responsible, it is logical (other things being equal) to assign it the responsibility for maintaining the information as well.
  • Keep information about one thing in one place. In general, the responsibility for knowing specific information should not be shared. Sharing information implies a duplication that could lead to inconsistency.
  • Share responsibilities among related objects. Occasionally, you may discover that a certain responsibility seems to be several responsibilities, or a compound responsibility, that is best divided or shared among two or more classes.


We now assign the responsibilities from the spreadsheet program.

open from a file
save to a file
It isn't clear which class to assign these responsibilities to. The closest candidate we have now is Spreadsheet itself, but it should be used to represent just the spreadsheet, not the full set of editing capabilities implied by the system. We therefore want a class that represents the application itself. Let's call this class Spreadsheet Editor, and assign these responsibilities to it.

maintain a collection of cells
This is clearly a responsibility of the class Spreadsheet. After all, that is the class that must maintain the collection; therefore, it should have the responsibility for maintaining the information as well.

cells have names
cells have values
By the same token, the responsibility for maintaining this information belongs to the class Cell.

rows have cells
columns have cells
The responsibility for maintaining this information belongs to the class Cell Group. However, because rows and columns are merely different groupings of cells, we might wish to rephrase this responsibility more generally, stating that the class Cell Group knows which cells it contains.

At this point, we might notice that the responsibilities of Spreadsheet and the responsibilities of Cell Group are very similar; they both maintain information about the cells they contain. We should view Spreadsheet as being composed of a group of cells, rather than maintaining a collection of individual cells. The responsibility of the class Spreadsheet is to know the group of cells of which it is composed. The responsibility of the clas Cell Group need not change.

rows have names
columns have names
Names of rows and columns appear merely by way of explaining how cells get named. Cells must maintain their names, as we mentioned above, but row and column names are irrelevant, and do not need to be maintained by any class. There is no responsibility for maintaining this information.

specify cell forma
This is actually a compound responsibility. The Spreadsheet Editor allows the user to specify the cell format, but the Cell must maintain its format thereafter.

numbers convert to text
The responsibility for performing this conversion belongs to the class Numeric Value.

users select rectangular groups of cells
cut selected cells
copy selected cells
paste cells
remove rows
remove columns
insert rows
insert columns
remove values of cells
replace values of cells
edit values of cells
The responsibility for receiving user input belongs to the class Spreadsheet Editor. Many of these responsibilities imply that other classes must perform other operations as well. We shall return to this point later, when we discuss collaborations.

recompute values of cells
This is also a compound responsibility. The Spreadsheet Editor allows the user to request that the values be recomputed, but the Expression must perform the actual computation.

Record responsibilities. As you assign responsibilities to specific classes, record them on the card for that class, under the class name, on the left edge.

DETERMINING COLLABORATIONS
A collaboration is a request made of one object by another. It is the embodiment of the requests specified in the client-server contract. A single collaboration flows in one direction--from the client to the server. Every collaboration is associated with a single responsibility. It fulfills, or contributes to the fulfillment of, that responsibility.

Collaborations are important because the pattern of collaborations within your application reveals how control and information will flow during execution. Identifying collaborations between classes allows you to identify paths of communication between classes. Finding such paths will ultimately allow you to identify subsystems of collaborating classes. Finding such subsystems is one way in which you will later be able to further abstract your application.

Identify collaborations. To identify collaborations, ask the following questions for each responsibility of each class:

  • Is the class capable of fulfilling this responsibility itself?
  • If not, what is needed?
  • From what other class can it acquire what it needs?

Let's look at each of the responsibilities assigned to the classes in the spreadsheet application. In general, responsibilities to maintain information require no collaborations. Unless they are an exception, we will not discuss such responsibilities.

Expression:
compute values
This generic operation requires no collaborations. However, subclasses of the class Expression require collaborations in order to fulfill their specific responsibilities, as described later.

Binary Expression:
compute values
This operation requires a collaboration with the expressions representing the arguments to the binary operator. These expressions may be a member of any subclass of the class Expression. We therefore record a collaboration with the class Expression.

Cell Reference Expression:
compute values
This operation requires a collaboration with the cell being referenced, an instance of the class Cell.

Numeric Value:
convert to text
This operation occurs during the computation of expressions. It requires no collaborations.

Spreadsheet Editor:
open from a file
save to a file
Clearly, this involves a collaboration with the class File.

allow user to specify cell format
This responsibility involves a collaboration with the class Cell so that the format will be remembered.

users select rectangular groups of cells
cut selected cells
copy selected cells
paste cells
remove rows
remove columns
insert rows
insert columns
remove values of cells
replace values of cells
edit values of cells
allow user to request to recompute values of cells
The Spreadsheet Editor is responsible for interpreting user input. It must then inform the spreadsheet that it has changed, requiring a collaboration with the class Spreadsheet. Responsibilities that alter cells or groups of cells must similarly collaborate with the classes Cell or Cell Group.

Record collaborations. Record these classes as collaborations on the card for that class directly opposite the responsibility the collaboration supports. Check to see that a corresponding responsibility exists for every collaboration you record. Remember, however, that a collaboration might be with a subclass, but the responsibility might be recorded on the superclass card instead.

Design walk-throughs. As you make these design decisions, it's important for you to be able to determine their implications. For this purpose, you should walk through your system after each step. Choose a set of typical inputs to your system, and hand-simulate its behavior, given these inputs. In this way, you can more easily determine the implications of your decisions. Feel free to revise previous decisions as you go, and walk through your new configuration. The point of this stage of your design process is, after all, to explore as many different possibilities as seems reasonable. Walk-throughs can help you determine the implications of these various possibilities.

Let's look at what happens when a cell is asked for its value. Cells maintain their values indirectly bystoring an instance of a subclass of class Value. Therefore, cells must retrieve their values when requested by sending a message to a Value. The Value may represent the value directly, as with a number or text, or it may know the expression by which the value can be computed. In the latter case, the Value must ask the expression to evaluate itself.

Expressions evaluate themselves differently depending on which type of expression they are. Constant Expressions evaluate themselves by returning the constant they represent. Cell Reference Expressions evaluate themselves by asking for the value of the cell they reference. Binary Expressions evaluate themselves by applying their operator to the values of their two arguments. So far, it seems the sys- tem works the way it was intended to.

THE ANALYSIS PHASE The analysis phase of object-based design also consists of three steps:

  1. Building optimal inheritance hierarchies.
  2. Streamlining the collaborations between classes.
  3. Defining the signatures for each responsibility.

Let's look at each of these steps individually.

BUILDING HIERARCHIES
A carefully considered and crafted inheritance hierarchy provides the maximum amount of reusable code. Carefully assigning responsibilities ensures that the resulting hierarchies of classes are easily reused, maintained, and extended.

Record existing hierarchies. First, examine the present class hierarchies in the design. Draw hierarchy graphs of your application. The hierarchy graph is rather simple. Classes are represented by rectangles, labeled with the class names. Inheritance is indicated by a line from superclass to subclass, and by position on the page--superclasses are above their subclasses.

Analyze the responsibilities assigned to each class to determine whether each class is abstract or concrete.

  • Abstract classes are designed to be inherited. Instances of abstract classes are never created as the system executes.
  • Concrete classes are designed to be instantiated. They are designed primarily so that their instances may be generally useful, and secondarily so that they may also be usefully inherited.

Go through your inheritance hierarchies, labeling each class as abstract or concrete on the cards and by filling in the upper-left corner of hierarchy graphs for abstract classes. If you have trouble deciding whether a given class is abstract or concrete, think about your working system. Will an instance of this class be used during execution? If so, the class is concrete.

Our spreadsheet program includes two abstract classes: Expression and Value. All other classes in this design are concrete. The hierarchy graphs for hierarchies containing more than one class appear as shown in Figure 2.

[IMAGE Object_Oriented_v004_htm3.GIF]

[IMAGE Object_Oriented_v004_htm4.GIF]

Figure 2. Hierarchy Graphs for Our Abstract Classes

Restructure hierarchies. Because our spreadsheet example is so small, there is nothing we can show you here to exemplify optimizing the hierarchy. Nevertheless, the following guidelines can help you build better hierarchies:

  • When you have determined how many abstract classes are presently in your design, speculate on abstract classes that might encapsulate behavior that could be reused by existing and future subclasses. In general, the more abstract classes an application has, the more code in the application can be reused. Therefore, define as many abstract classes as seems reasonable to capture the abstractions present in your design, or that you reasonably suspect you might have future use for.
  • Factor responsibilities as high as possible in the hierarchy. If a set of classes all support the same set of responsibilities, all the classes should inherit those responsibilities from a common superclass. If a common superclass does not exist, create one, and move the common responsibilities to it. After all, such a class is demonstrably useful--you have already shown that the responsibilities will be inherited by some classes.
  • Factor implementation details as low as possible in the hierarchy. If a superclass supports its responsibilities in only the most generic possible way, (providing only templates, as it were, for the desired behavior), then implementation details cannot impede a new subclass from inheriting those responsibilities. Each subclass is free to implement the responsibilities in the way most appropriate for it. This can include subclasses unforeseen by the original design.
  • Ensure that each class encapsulates a single integral set of responsibilities. Each class should have a single, overarching purpose; each class should serve one main function in the system of which it is a part. These observations of what enhances or detracts from the reusability of a class lead to the principle that the appropriate use of inheritance is to model a type hierarchy: every class should be a particular kind of its superclasses. Subclasses should add responsibilities to their superclasses; they should not cancel inherited responsibilities, or override them to become errors, or no behavior at all.

When you have modified your design, redo your graphs and cards to correspond to the new state of your design. Then recheck your system. For each responsibility, make sure there is a corresponding collaboration, and vice versa. Once again, walk through the design to ensure that every object is still communicating with the rest of the system in the appropriate manner.

Group responsibilities into contracts. Once the responsibilities have been properly factored in the hierarchies, they need to be grouped into the contracts supported by each class. This is usually straightforward because classes usually support a small and cohesive set of responsibilities. If the responsibilities of a class are not cohesive, it should have more than one contract. Not all responsibilities will be public behavior for the class. Only public behavior should be grouped into contracts. Number the contracts so that they can be referenced.


Here are the contracts for the classes in the spreadsheet design:

Cell 1. Maintain the value and format 2. Compute the value

Cell Group 3. Know the cells contained in the group

Expression 4. Compute the value of the expression

File 5. Input and output to disk

Spreadsheet 6. Know the group of cells within it

Value 7. Compute the value represented

STREAMLINING COLLABORATIONS
We are now going to streamline the collaborations between classes--each communication path that can occur as information and execution flows through the system. We analyze these collaborations to attain an overall perspective, to identify natural ways to divide responsibilities between groups of classes, and thereby to simplify the various ways in which communication can flow. Simplifying the potential communication flow simplifies the application: the application becomes easier for others to understand, maintain, reuse, refine, and extend.

Earlier, we discussed performing a walk-through of your system, trying out various scenarios, simu- lating the results of various typical inputs. Each such scenario brings to light one possible path along which information and control can flow.

To do a good job of analyzing collaborations between objects, you must first collect an exhaustive description of all the paths along which control and information can flow. You can then analyze the col - laborations between classes in order to simplify them.

A collaborations graph is a tool for accomplishing this analysis. A collaborations graph allows you to examine the collaborations between classes in graphical form, so that you can better identify areas of unnecessary complexity or other design flaws. Collaborations graphs represent four distinct elements: classes, subsystems, contracts, and collaborations.

Classes are shown as labeled rectangles. Subsystems are shown by drawing a rounded rectangle around the classes that comprise them. Contracts are shown as small semicircles inside the edges of the class or subsystem to which they belong. Draw one semicircle per contract, labeled by the contract number. Collaborations between classes or subsystems are represented by an arrow from the client to a contract supported by the server. If two objects both collaborate with a class by means of the samecontract, draw the arrows to the same semicircle. Otherwise, draw the arrows to different semicircles.

In addition, collaborations graphs show superclass/subclass relationships, such as that between the class Value and the specific kinds of values, or between Expression and the different kinds of expressions. A superclass represents the contracts supported by all of its subclasses; because of polymorphism, we can focus on the abstract contract. We need not consider whether the superclass, or one of its subclasses, will be the object actually providing the service during execution. This is represented in the collaborations graph by nesting subclasses within the bounds of their superclasses.

Figure 3 shows the collaborations graph of the spreadsheet application as we have so far designed it.

[IMAGE Object_Oriented_v004_htm5.GIF]

Figure 3. Initial Collaborations Graph for Our Spreadsheet Program

The goal of this step in the design process is to simplify the patterns of collaboration. Without such simplification, the communication paths could flow from nearly any class to any other, with only the slenderest of justifications and no coherent structuring. Such anarchic flow leads to spaghetti code-- the same problem that eliminating "go to" statements was designed to avoid.

Because such applications are impossible to maintain or sensibly modify, we aim to simplify the patterns of collaboration. Successfully doing so translates into a simplification of the graph. The technique we will use, at least in part, is to work backward: we shall simplify the graph in order to simplify the collaborations. What criteria should you use to accomplish this simplification?

  • Minimize the number of different contracts supported by each class and subsystem. Too many contracts for one class or subsystem can be a sign that too much of the application's intelligence is concentrated in that class or subsystem.
  • Each contract supported by a subsystem should be handled by only one class or subsystem. If the contract representing the external interface of a subsystem mediates direct collaborations with two or more classes, it can be a sign that a level of indirection is missing, or that the contract is really two or more con - tracts.
  • Minimize the number of classes and subsystems within a subsystem that are collaborated with by classes or subsystems outside the subsystem. Otherwise, your subsystem does not truly encapsulate its component entities. It does not provide the desired level of abstraction.

Three basic mechanisms can be used to simplify your graph, and hence to streamline the collabora- tions between your classes and subsystems.

  • Build clean subsystems by centralizing communications to a subsystem or introducing an intermediary to a subsystem.
  • Coalesce classes whose responsibilities overlap.
  • Split classes with too many contracts.

Our spreadsheet application can be cleanly divided into two large pieces: the editing capabilities and the structure being edited. For this reason, it makes sense to create a subsystem representing the structure of a spreadsheet, which we will call the Spreadsheet Subsystem. The Spreadsheet Subsystem is responsible for creating spreadsheets, and maintaining their structure.

It may well be that the Spreadsheet Editor is itself really a subsystem rather than a single class, but in the interests of simplicity let's presume that it is a class.

Having created the Spreadsheet Subsystem, we need to clean up the way in which the Spreadsheet Editor collaborates with it. In particular, the Spreadsheet Editor should not collaborate with so many of the classes inside the subsystem. We can simplify the paths of collabora- tion by forcing all accesses to other classes to go through the Spreadsheet. This implies that Spreadsheets must be able to understand and pass along all messages to the cells or cell groups that compose them. Spreadsheets therefore now collaborate with Cell Groups, which in turn collaborate with Cells. Two new collaborations therefore appear in the graph.

This set of changes results in the graph of the application shown in Figure 4.

[IMAGE Object_Oriented_v004_htm6.GIF]

Figure 4. Simplified Collaborations Graph for Our Spreadsheet Program

The collaborations within the Spreadsheet Subsystem would then look like Figure 5.

[IMAGE Object_Oriented_v004_htm7.GIF]

Figure 5. Collaborations Graph for the Spreadhseet Subsystem

DEFINING SIGNATURES

Once the responsibilities have been assigned to classes, and changes are unlikely, the final stage of the design process is to refine the responsibilities into protocols. A protocol is a set of messages to which an object will respond.

The goal of this part of the process is to make the classes in your application, particularly their instances, as generally useful as possible. This is accomplished in two ways:

  • Maximize polymorphism. Polymorphism, as you recall, is the ability of instances of different classes to respond to the same message, each in its own appropriate way. Polymorphism has already been maximized by moving responsibilities as high in the hierarchy as they can reasonably go. By moving a responsibility from a class to its superclass, you increase the number of classes that can support that responsibility, and hence respond to that message. Polymorphism can also be maximized by carefully selecting message names, so that it makes sense for instances of many classes to respond to messages by those names. Use a single message name for each conceptual operation, wherever in the system it is found. Likewise, associate a single conceptual operation with each mes- sage name.
  • Make the protocol as generally useful as possible. Instances will be more reusable if the protocols used to make requests of them have been designed in anticipation of as many different uses as possible. Think about what might change if the system were modified or extended. Think about what related systems might wish to use.

First, define the most general message, one that allows clients to supply all possibly required parameters. Next, provide reasonable default behavior for as many parameters as possible. Finally, analyze how each client uses (or is likely in the future to use) this general message. From that analysis, define a useful set of messages that allows clients to specify only some of the parameters, while relying on the defaults for the others.

List the contracts of each class or subsystem in your application, and turn each contract into a set of signatures. Each contract will have one or several messages associated with it. Name these messages thoughtfully, bearing in mind the considerations just described. Along with the message names, specify the types of all arguments required, and the type of object returned by the method, if any. Here is an example set of signatures for the class Spreadsheet:

Class: Spreadsheet 6. Know the group of cells within it

  • cells() returns Cell Group
  • cells(Cell Group) returns void
  • row(Integer) returns Cell Group
  • column(Integer) returns Cell Group
  • rows(Integer, Integer) returns Cell Group
  • columns(Integer, Integer) returns Cell Group
  • rowsAndColumns(Integer, Integer, Integer, Integer) returns Cell Group
  • positionOfCell(Cell) returns String
  • cellAt(Integer, Integer) returns Cell
  • cellNamed(String) returns Cell

You are now ready to write a formal specification for each class. The specification will state the name of the class and its overall purpose, whether it is abstract or concrete, its position in its inheritance hierarchy and the collaborations graph, and its contracts and their associated signatures. Each signature should be followed by a description of the behavior captured by the signature. In addition, include any notes on special implementation considerations, such as algorithms, behavioral constraints, or error conditions.

As a result of this design process, you now have one or more collaborations graphs, one or more hierarchy graphs, a specification for each class, and a set of formal contracts for each class.

You are now ready to implement your application.

CONCLUSION

The result of this process is a design based on objects. The responsibilities of each object become messages to which the object will respond by providing the services requested. Collaborations represent classes from which an object must request operations or information in order to fulfill its own responsibilities.

The design therefore supports the basic concepts of object-based technology--it encapsulates operations and information within objects, it hides details of the state of an object, and it uses inheritance to incrementally refine the definitions of objects, maximizing the amount of reusable code.

Classes and subsystems can be tested before they are connected to the entire application. Because the paths of communication are mapped out and rigorously controlled, maintenance can be performed without risking unpredictable side-effects. Finally, because the software has been designed from the start with future extensions in mind, functionality can be added to the application with a minimum of difficulty.

Applications implemented from such a design can therefore reap the benefits of object-based technology.

THE SPREADSHEET SPECIFICATION

The spreadsheet program is an application that allows users to create and edit electronic spreadsheets.

Users can create new spreadsheets. Existing spreadsheets can be opened from and saved to files.

The Spreadsheet
A spreadsheet is a collection of cells arranged in rows and columns.

Rows and columns consist of cells and have names. The name of a column is the letter C followed by the ordinal position of that column. The name of a row is the letter R followed by the ordinal position of thatrow.

Each cell has a name and a value. The name of a cell is the concatenation of the name of the cell's column and the name of the cell's row, in either order.

There are three different types of cells: numeric, text, and expression.

Numeric cells contain numeric values. The user can specify the format in which the value of a numeric cell is displayed. There are four different formats:

  • integer (no decimal point)
  • monetary (two places after the decimal point, preceded by a dollar sign)
  • real (one or more places after the decimal point)
  • scientific (as a value between zero and one, and an exponent)

Text cells contain arbitrary text, except that the first character cannot be an equal sign. The text can be formatted to be left aligned, centered, right aligned, or fully justified.

Expression cells contain a formula, but display the value of the formula. Formulas are entered as text, using the syntax defined by the following syntax definition:

<formula> ::= '=' <expression>
<expression> ::= [<expression> ','] <simple expression>
<simple expression> ::=
    [<simple expression> <additive operator>] <term>
<term> ::= [<term> <multiplicative operator>] <factor>
<factor> ::= <constant> | <cell name> | '(' <expression> ')'
<constant> ::= <number> | <text>
<additive operator> ::= '+' | '-'
<multiplicative operator> ::= '*' | '/'

Arguments to additive and multiplicative operators must be numeric. The result is a number. Arguments to the comma operator (text concatenation) may be either text or numbers, the numbers being converted to a textual representation in the latter case. The result is text.

The value of an expression cell can be formatted either as numeric cells or text cells, depending on the type of the result.

Operations
Users must be able to select rectangular groups of cells, from individual cells to the entire spreadsheet, including rows and columns. Selected cells can be cut, copied, and pasted. At least one cell must be selected at all times.

If one or more complete rows or columns are selected and cut, the rows or columns are removed from the spreadsheet. If one or more rows or columns are pasted, they are inserted to the left of or above the topmost selected row or column, respectively.

If a portion of some rows and columns is cut, the values in those cells are removed, but the empty cells remain. If such a portion is pasted, the values of the same shape of cells are replaced with the values of the cells, with the upper leftmost cell in the paste buffer being aligned with the upper leftmost cell of the selected cells.

Users must have the ability to edit the values in individual cells, and to force recomputation of the values shown in expression cells.

FURTHER READING ON OBJECT-BASED DESIGN.

  • Beck, Kent, and Ward Cunningham, "A Laboratory for Teaching object-based Thinking," OOPSLA'89 Conference Proceedings , SIGPLAN Notices, October 1989, pp. 1-6.
  • Cox, Brad, "Message/Object Programming: An Evolutionary Change in Programming Technology," IEEE Software, January 1984, pp. 50-61.
  • Halbert, Daniel, and Patrick O'Brien, "Using Types and Inheritance inobject-based Languages," IEEE Software, September 1987, pp. 71-79.
  • Johnson, Ralph, and Brian Foote, "Designing Reusable Classes," Journal of object-based Programming, June/July 1988, pp. 22-35.
  • LaLonde, Wilf, "Designing Families of Data Types Using Exemplars," ACM
  • Transactions on Programming Languages and Systems, April 1989, pp. 212-248.
  • Meyer, Bertrand, "Reusability: The Case for object-based Design," IEEE Software, March 1987, pp. 50-64.
  • Snyder, Alan, "Encapsulation and Inheritance in object-based Programming Languages," OOPSLA'86 Conference Proceedings , SIGPLAN Notices, November 1986, pp. 38-45.
  • Wirfs-Brock, Allen, and Brian Wilkerson, "Variables Limit Reusability," Journal of object-based Programming , May/June 1989, pp. 34-40.
  • Wirfs-Brock, Rebecca, and Brian Wilkerson, "Object-based Design: A Responsibility-Driven Approach," OOPSLA'89 Conference Proceedings , SIGPLAN Notices, October 1989, pp. 71-76.
  • C++ Primer, Stanley B. Lippman, Addison Wesley, 1989
  • C++ Programming Language, Bjarne Stroustrup, Addison Wesley, 1987
  • Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988
  • MPW C++ 3.1b1 Reference Manual, Apple Computer, 1989 (APDA, part of MPW C++ 3.1b1 Product)

BRIAN WILKERSON is an object-oriented systems specialist for Instantiations, Inc., a consulting firm in Portland, Oregon. He studied computer science at the University of Alberta. After receiving his degree, he worked for Tektronix prior to joining his current company. Brian has developed a course about object-oriented design at Instantiations, and has also co-authored a book entitled Designing Object-Oriented Software, to be published this spring by Prentice-Hall. When he's not writing or working, he enjoys day hiking and attending jazz concerts. *

 
AAPL
$97.03
Apple Inc.
-0.16
MSFT
$44.40
Microsoft Corpora
-0.47
GOOG
$593.35
Google Inc.
-2.63

MacTech Search:
Community Search:

Software Updates via MacUpdate

Audio Hijack Pro 2.11.0 - Record and enh...
Audio Hijack Pro drastically changes the way you use audio on your computer, giving you the freedom to listen to audio when you want and how you want. Record and enhance any audio with Audio Hijack... Read more
Intermission 1.1.1 - Pause and rewind li...
Intermission allows you to pause and rewind live audio from any application on your Mac. Intermission will buffer up to 3 hours of audio, allowing users to skip through any assortment of audio... Read more
Airfoil 4.8.7 - Send audio from any app...
Airfoil allows you to send any audio to AirPort Express units, Apple TVs, and even other Macs and PCs, all in sync! It's your audio - everywhere. With Airfoil you can take audio from any... Read more
Microsoft Remote Desktop 8.0.8 - Connect...
With Microsoft Remote Desktop, you can connect to a remote PC and your work resources from almost anywhere. Experience the power of Windows with RemoteFX in a Remote Desktop client designed to help... Read more
xACT 2.30 - Audio compression toolkit. (...
xACT stands for X Aaudio Compression Toolkit, an application that encodes and decodes FLAC, SHN, Monkey’s Audio, TTA, Wavpack, and Apple Lossless files. It also can encode these formats to MP3, AAC... Read more
Firefox 31.0 - Fast, safe Web browser. (...
Firefox for Mac offers a fast, safe Web browsing experience. Browse quickly, securely, and effortlessly. With its industry-leading features, Firefox is the choice of Web development professionals... Read more
Little Snitch 3.3.3 - Alerts you to outg...
Little Snitch gives you control over your private outgoing data. Track background activityAs soon as your computer connects to the Internet, applications often have permission to send any... Read more
Thunderbird 31.0 - Email client from Moz...
As of July 2012, Thunderbird has transitioned to a new governance model, with new features being developed by the broader free software and open source community, and security fixes and improvements... Read more
Together 3.2 - Store and organize all of...
Together helps you organize your Mac, giving you the ability to store, edit and preview your files in a single clean, uncluttered interface. Smart storage. With simple drag-and-drop functionality,... Read more
Cyberduck 4.5 - FTP and SFTP browser. (F...
Cyberduck is a robust FTP/FTP-TLS/SFTP browser for the Mac whose lack of visual clutter and cleverly intuitive features make it easy to use. Support for external editors and system technologies such... Read more

Latest Forum Discussions

See All

LEX Goes Free For One Day In Honor of Ne...
LEX Goes Free For One Day In Honor of New Update Posted by Jennifer Allen on July 24th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Thomas Was Alone Goes Universal, Slashes...
Thomas Was Alone Goes Universal, Slashes Price to $3.99 Posted by Ellis Spice on July 24th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Meerkatz Challenge Review
Meerkatz Challenge Review By Jennifer Allen on July 24th, 2014 Our Rating: :: FONDLY PUZZLINGUniversal App - Designed for iPhone and iPad Cute and challenging, Meerkatz Challenge is a fun puzzle game, particularly for fans of... | Read more »
Book Your Appointment with F.E.A.R. this...
Book Your Appointment with F.E.A.R. | Read more »
It Came From Canada: Epic Skater
For all the hate that it gets for being a pastime for slackers, skateboarding really does require a lot of skill. All those flips and spins take real athleticism, and there’s all the jargon to memorize. Fortunately for us less extreme individuals,... | Read more »
Cultures Review
Cultures Review By Jennifer Allen on July 24th, 2014 Our Rating: :: SLOW-PACED EMPIRE BUILDINGiPad Only App - Designed for the iPad Cute it might seem, but Cultures is a bit too slow paced when it comes to those pesky timers to... | Read more »
More Paintings Have Been Added to Paint...
More Paintings Have Been Added to Paint it Back! Posted by Jessica Fisher on July 24th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
The Order of Souls Review
The Order of Souls Review By Campbell Bird on July 24th, 2014 Our Rating: :: STORY GRINDUniversal App - Designed for iPhone and iPad The Order of Souls is a free-to-play, turn-based RPG with a genre-mixing art style, interesting... | Read more »
Revolution 60 Review
Revolution 60 Review By Jordan Minor on July 24th, 2014 Our Rating: :: LASS EFFECTUniversal App - Designed for iPhone and iPad Revolution 60 is a bold, cinematic action game with ambition to spare.   | Read more »
Matter (Photography)
Matter 1.0.1 Device: iOS Universal Category: Photography Price: $1.99, Version: 1.0.1 (iTunes) Description: Add stunning 3D effects to your photos with real-time shadows and reflections. Export your creations as photos or video loops... | Read more »

Price Scanner via MacPrices.net

Save on 5th generation refurbished iPod touch...
The Apple Store has Apple Certified Refurbished 5th generation iPod touches available starting at $149. Apple’s one-year warranty is included with each model, and shipping is free. Many, but not all... Read more
What Should Apple’s Next MacBook Priority Be;...
Stabley Times’ Phil Moore says that after expanding its iMac lineup with a new low end model, Apple’s next Mac hardware decision will be how it wants to approach expanding its MacBook lineup as well... Read more
ArtRage For iPhone Painting App Free During C...
ArtRage for iPhone is currently being offered for free (regularly $1.99) during Comic-Con San Diego #SDCC, July 24-27, in celebration of the upcoming ArtRage 4.5 and other 64-bit versions of the... Read more
With The Apple/IBM Alliance, Is The iPad Now...
Almost since the iPad was rolled out in 2010, and especially after Apple made a 128 GB storage configuration available in 2012, there’s been debate over whether the iPad is a serious tool for... Read more
MacBook Airs on sale starting at $799, free s...
B&H Photo has the new 2014 MacBook Airs on sale for up to $100 off MSRP for a limited time. Shipping is free, and B&H charges NY sales tax only. They also include free copies of Parallels... Read more
Apple 27″ Thunderbolt Display (refurbished) a...
The Apple Store has Apple Certified Refurbished 27″ Thunderbolt Displays available for $799 including free shipping. That’s $200 off the cost of new models. Read more
WaterField Designs Unveils Cycling Ride Pouch...
High end computer case and bag maker WaterField Designs of San Francisco now enters the cycling market with the introduction of the Cycling Ride Pouch – an upscale toolkit with a scratch-free iPhone... Read more
Kingston Digital Ships Large Capacity Near 1T...
Kingston Digital, Inc., the Flash memory affiliate of Kingston Technology Company, Inc.,has announced its latest addition to the SSDNow V300 series, the V310. The Kingston SSDNow V310 solid-state... Read more
Apple’s Fiscal Third Quarter Results; Record...
Apple has announced financial results for its fiscal 2014 third quarter ended June 28, 2014, racking up quarterly revenue of $37.4 billion and quarterly net profit of $7.7 billion, or $1.28 per... Read more
15-inch 2.0GHz MacBook Pro Retina on sale for...
B&H Photo has the 15″ 2.0GHz Retina MacBook Pro on sale for $1829 including free shipping plus NY sales tax only. Their price is $170 off MSRP. B&H will also include free copies of Parallels... Read more

Jobs Board

*Apple* Solutions Consultant (ASC) - Apple (...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
Project Manager / Business Analyst, WW *Appl...
…a senior project manager / business analyst to work within our Worldwide Apple Fulfillment Operations and the Business Process Re-engineering team. This role will work Read more
Sr. Manager, *Apple* Deployment Programs fo...
**Job Summary** Apple is seeking candidates for a new position on the Education Content and Technology team. iPad and Mac is in the hands of millions of teachers and Read more
Sr Software Lead Engineer, *Apple* Online S...
Sr Software Lead Engineer, Apple Online Store Publishing Systems Keywords: Company: Apple Job Code: E3PCAK8MgYYkw Location (City or ZIP): Santa Clara Status: Full Read more
Senior Interaction Designer, *Apple* Online...
**Job Summary** Apple is looking for a hands on Senior…will be a key player in designing for the Apple Online Store. The ideal designer will have a Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.