Object-Oriented Design - Java Concepts - page 769

Does the ATM class aggregate Bank ? To answer this question, ask yourself whether
an ATM object needs to store a reference to a bank object. Does it need to locate
the same bank object across multiple method calls? Indeed it does. Therefore,
aggregation is the appropriate relationship.
Does an ATM aggregate customers? Clearly, the ATM is not responsible for storing
all of the bank's customers. That's the bank's job. But in our design, the ATM
remembers the current customer. If a customer has logged in, subsequent
commands refer to the same customer. The ATM needs to either store a reference
to the customer, or ask the bank to look up the object whenever it needs the current
customer. It is a design decision: either store the object, or look it up when needed.
We will decide to store the current customer object. That is, we will use
aggregation. Note that the choice of aggregation is not an automatic consequence of
the problem descriptionȌit is a design decision.
Similarly, we will decide to store the current bank account (checking or savings)
that the user selects. Therefore, we have an aggregation relationship between ATM
and BankAccount .
The class diagram is a good tool to visualize dependencies. Look at the GUI
classes. They are completely independent from the rest of the ATM system. You
can replace the GUI with a console interface, and you can take out the Keypad
class and use it in another application. Also, the Bank , BankAccount , and
Customer classes, although dependent on each other, don't know anything about
the ATM class. That makes senseȌyou can have banks without ATMs. As you can
see, when you analyze relationships, you look for both the absence and presence of
relationships
12.5.4 Method Documentation
Now you are ready for the final step of the design phase: to document the classes
and methods that you discovered. Here is a part of the documentation for the ATM
class:
/**
An ATM that accesses a bank.
*/
public class ATM