|
|
|
|
|
|
|
and customer. The operations on a savingsAccount object are suggested by the list of verb phrasesnamely, Deposit, Withdraw, and PayInterest. What are the operations on a customer object? We would need more information from the rest of the problem definition in order to answer this question. In fact, customer may not turn out to be a useful object at all. The nouns-and-verbs technique is only a starting pointit points us to potential objects and operations. |
|
|
|
|
|
|
|
|
Determining which nouns and verbs are significant is one of the most difficult aspects of OOD. There are no cookbook formulas for doing so, and there probably never will be. Not all nouns become objects, and not all verbs become operations. The nouns-and-verbs technique is imperfect, but it does give us a first approximation to a solution. |
|
|
|
|
|
|
|
|
The solution domain includes not only objects drawn from the problem domain but also implementation-level objects. These are objects that do not model the problem domain but are used in building the program itself. In systems with graphical user interfacesMicrosoft Windows or the Macintosh operating system, for examplea program may need several kinds of implementation-level objects: window objects, menu objects, objects that respond to mouse clicks, and so on. Objects such as these are often available in class libraries so that we don't need to design and implement them from scratch each time we need them in different programs. |
|
|
|
|
|
|
|
|
Step 2: Determine the Relationships Among Objects |
|
|
|
|
|
|
|
|
After selecting potential objects and operations, the next step is to examine the relationships among the objects. In particular, we want to see whether certain objects might be related either by inheritance or by composition. Inheritance and composition relationships not only pave the way for code reuseas we emphasized in our discussion of OOPthey also simplify the design and allow us to model the problem domain more accurately. For example, the banking problem may require several kinds of savings accountsone for general customers, another for preferred customers, and another for children under the age of 12. If these are all variations on a basic savings account, the is-a relationship (and, therefore, inheritance) is probably appropriate. Starting with a SavingsAccount class that provides operations common to any savings account, we could design each of the other accounts as a child class of SavingsAccount, concentrating our efforts only on the properties that make each one different from the parent class. |
|
|
|
|
|
|
|
|
Sometimes the choice between inheritance and composition is not immediately clear. Earlier we wrote a TimeCard class to represent an employee's time card. Given an existing Time class, we used composition to relate TimeCard and Timethe private part of the TimeCard class is composed of a Time object (and an ID number). We could also have used inheritance. We could have derived class TimeCard from Time (inheriting the hours, minutes, and seconds members) and then specialized it by adding an extra data mem- |
|
|
|
|
|