6.5 Functional Decomposition | 285
Inheritance
In walking through the scenario in which the user requests a business address, we notice that
the Work Address class is nearly identical to the Address class, except that it also provides
a Work Name and a Second Address Line. Rather than copy all of the responsibilities and col-
laborations from the Address card to this one, we can list Address as the superclass of Work
Address.
Because Business Address is a subclass of Address, it inheritsall of the re-
sponsibilities that are in Address. A subclass is automatically able to use the re-
sponsibilities of its superclass and also add its own unique responsibilities. In
addition, a subclass can replace an inherited responsibility with a new defini-
tion of the responsibility. The new definition provides a way to retain the same
form of interface, but customize its implementation to reflect the differences be-
tween the superclass and the subclass. In OOD, this concept is called inheritance,
and it allows you to adapt an existing class to satisfy additional responsibilities.
All classes in Java are actually subclasses of a master class called Object. They form a hi-
erarchy of subclasses and superclasses that may be many levels deep. As we will see in
Chapter 7, looking at the definition of a class in the Java library may reveal only a small por-
tion of its capabilities, like the tip of an iceberg. Its superclasses may define many more fea-
tures that it inherits. The inheritance mechanism is a very powerful tool in object-oriented
design, enabling us to reuse existing code easily and flexibly. In this way, we can gradually
build up classes, one on top of another, until we have classes with very extensive capabili-
ties. Yet at each stage, the capabilities are added in a clear and simple manner, making the
code easy to manage and maintain.
To summarize the CRC card process, we brainstorm the objects in a problem and abstract
them into classes. Then we filter the list of classes to eliminate duplicates and unnecessary
items. For each class, we create a CRC card and list any obvious responsibilities that it should
support. We then walk through a common scenario, recording responsibilities and collabo-
rations as they are discovered. Next, we walk through additional scenarios, moving from
common cases to special and exceptional cases. When it appears that we have all of the
scenarios covered, we brainstorm additional scenarios that may need more responsibilities
and collaborations. When our ideas for scenarios are exhausted and all the scenarios are cov-
ered by the existing CRC cards, the design is done.
6.5 Functional Decomposition
The second design technique we use is functional decomposition (also calledstructured design,
top-down design, stepwise refinement, andmodular programming). It allows us to use the divide-
and-conquer approach, which we presented in Chapter 1. We apply this technique to design-
ing the algorithms that implement the responsibilities for an object-oriented design.
Inheritance A mechanism that
enables us to define a new class
by adapting the definition of an
existing class