Java Reference
In-Depth Information
remaining cards, we can quickly see that we have two cards that are accounts:
“Capital Account” and “Current Account.” These are both pools of money.
Put them on top of one another on the table. Likewise, it is fairly obvious that
“CEO,” “CFO,” “Director,” and “Manager” are all people. Put them together
on the table.
Remember that we are looking for simplifying abstractions. The grouped
cards should all be obviously variant types of a generic class of objects. In our
example, the one is a stack of Accounts, and the other is a stack of People, or,
as we will call them, Users. Create new cards for these generic classes. Make a
card with “Account” at the top and put it above the first stack. Make another
card with “User” at the top and put it above the second stack.
There are two ways that this might simplify your design. For now, all cards
below the abstract cards are “on probation.” We are going to move on to define
the attributes (data) and methods (behavior) of our abstract classes. If the ab-
stract class can handle all use cases without having to treat any of the more
specific classes differently, then the specific cards are discarded. If not, then all
functionality that is common across the more specific types will be put on the
abstract class card, and only those data and behaviors that are different will be
put on the more detailed cards.
In the first case, the simplification is a reduction of several potential classes
to a single class. This is always a good thing, when it is possible. In the second
case, you are identifying potential inheritance relationships.
4
12.5
F
INDING THE
M
ETHODS AND
A
TTRIBUTES
The next step is to start identifying the data and behavior that characterize your
classes. Always put such items on the most abstract class first. The only time to
add an attribute or method to a more specific class is when it applies to that
class and only that class—in other words, only when it represents a difference
between the general case and the specific case.
5
4. We'll talk more about that later in the topic. As it happens, all of our simplifications in this
chapter are examples of the first case.
5. In complex cases, you may find an attribute or method that applies to several, but not all,
of the specific cases. In such a case, a new abstract class below the main abstract class, but above
all the specific classes that share that attribute or method, may be called for.
