Object-Oriented Analysis and Design 35311
Note that in Figure 11.12,CheckingAccounthas already been captured as a specializa-
tion of Account. You didn’t set out to find the generalization relationship, but this one
was self-evident, so it has been captured. Similarly, from the domain analysis, you know
that the ATMdispenses both Cashand Receipts, so that information has been captured
immediately into the design.
The relationship between Customerand CheckingAccountis less obvious. Such a rela-
tionship exists, but the details are not obvious, so you should hold off.
Other Transformations....................................................................................
After you have transformed the domain objects, you can begin to look for other useful
design-time objects. Often, each actor has a class. A good starting place is with the inter-
face between your new system and any existing systems—this should be encapsulated in
an interface class. However, be careful when considering databases and other external
storage media. It is generally better to make it a responsibility of each class to manage its
own “persistence”—that is, how it is stored and retrieved between user sessions. Those
design classes, of course, can use common classes for accessing files or databases, but
most commonly, the operating system or the database vendor provides these to you.
These interface classes allow you to encapsulate your system’s interactions with the other
system, and, thus, shield your code from changes in the other system. Interface classes
allow you to change your own design, or to accommodate changes in the design of other
systems, without breaking the rest of the code. As long as the two systems continue to
support the agreed-on interface, they can change independently of one another.
Data Manipulation
Similarly, you might need to create classes for data manipulation. If you have to trans-
form data from one format into another format (for example, from Fahrenheit to Celsius
or from English to Metric), you might want to encapsulate these transformations behind
a special class. You can use this technique when converting data into required formats for
other systems or for transmission over the Internet—in short, any time you must manipu-
late data into a specified format, you encapsulate the protocol behind a data manipulation
class.
Views and Reports
Every “view” or “report” your system generates (or, if you generate many reports, every
set of reports) is a candidate for a class. The rules behind the report—both how the infor-
mation is gathered and how it is to be displayed—can be productively encapsulated
inside a view class.