Java Reference
In-Depth Information
To take our example, suppose we have the following list of CRC cards
after such an open brainstorming session:
• Database
• Capital Account
• Current Account
• CEO
• Computer
• CFO
• Director
• Keyboard
• Manager
Where do you go from here? Let's articulate a general principle.
The first principle.
If we could teach a programmer only one thing about
software design, it would be this idea: less is more. Or, to quote Antoine de
Saint-Exupéry: “Perfection is achieved not when nothing can be added, but
when nothing can be taken away.” Or, to put it yet another way, always use
the KISS
3
principle. The best object design is the smallest possible number of
classes that model the real objects and meet all the requirements.
You are seeking simplifying abstractions.
First of all, all the objects that represent technologies or implementation
details should be removed. In our list, this would include “Database,” “Com-
puter,” and “Keyboard.” While it is likely that all three will be involved in the
final product, they are not objects in the problem space. There is no theoretical
reason why an OOA session cannot produce a manual, noncomputer solution.
It is a common tendency to leap from problem analysis directly to technical
solutions. “We can write that in Java,” “We can store those in Oracle,” “That
could be an XML file.” Statements like these are to be avoided at this stage.
Those are details about the implementation. You haven't got a design to
implement yet!
As we said, you are seeking simplifying abstractions. The next step, after
culling cards that do not represent real objects in the problem space, is to
group together the cards that have any attributes in common. If we look at our
3. An acronym for:
Keep It Simple, Stupid!
