Designing an Object-Oriented System

In top-down structured programming, the first design step is to specify the program's intended function. You must answer the question, “What does the program do?” First you describe the major steps that the program must perform, using high-level pseudocode or flowcharts, and then you refine that description by breaking each major step into smaller ones. This technique is known as “procedural decomposition.” It treats a program as a description of a process, and breaks it down into subprocesses.

Object-oriented design differs dramatically from this technique. In object-oriented design, you don't analyze a problem in terms of tasks or processes. Nor do you describe it in terms of data; you don't begin by asking “What data does the program act upon?” Instead, you analyze the problem as a system of objects interacting. The first question you ask is, “What are the objects?” or “What are the active entities in this program?”

Not only does object-oriented design begin from a different premise from procedural decomposition, it proceeds in a different manner. Procedural decomposition is a top-down approach, starting with an abstract view of the program and ending with a detailed view. However, object-oriented design is not a top-down technique. You do not first identify large classes and then break them down into smaller ones. Nor is it necessarily a bottom-up process, where you start with small classes and build up from them (though class libraries can be used for this kind of approach). Object-oriented design involves working at both high and low levels of abstraction at all stages.

Object-oriented design requires you to do the following:

Identify the classes

Assign attributes and behavior

Find relationships between the classes

Arrange the classes into hierarchies

While you should begin by performing these steps in the order shown, remember that object-oriented design is an iterative process. If you perform each step in the process just once, without regard for the later steps, it's unlikely that you'll create a useful set of classes. Each step in the process may alter the assumptions you used in a previous step, requiring you to go back and repeat that step with new information. This does not mean that you shouldn't give any thought to your initial design. A good initial design is always desirable and will speed up the development process. However, you should expect revisions to occur. You will successively refine your class descriptions throughout the design process.