Chapter 12. Analysis and Design: Seeking the Objects
In this chapter, we will present the barest outline of a software development methodology. For some readers, this will be simplistic and unsuitable. In our experience, however, there are many businesses out there with very small development
12.1. What You Will Learn
In this chapter you will learn a very simple method for object discovery and a simple method of documenting this process.
12.2. Facing the Blank Page
So, you have some requirements. Maybe you even have some UI
The simplest way is to start with real-world objects. Stop thinking about everything you have read about object-oriented programming. Instead, ask yourself, "What are the real objects involved in this problem?"
In our case, the more you look at it, the simpler it gets. For the moment, the only real objects we have are peoplethe usersand accounts, that is, named pools of money. We know that users get accounts from "above," and that they may break those pools down into subaccounts, which they may own or delegate to other users.
At the broadest level, then, we seem to have two "classes" or types of real-world objects: Accounts and Users.
12.3. Using CRC Cards
So, we need two classes. But what goes into those classes? How do we go about
In their now (semi)famous paper presented at the object-oriented programming conference OOPSLA in 1989, Kent Beck and Ward Cunningham introduced a simple, practical design tool for object-oriented design based on a simple, practical 3x5 file card. The CRC cards for our classes are shown in Figures 12.1 and 12.2.
Figure 12.1. Account CRC card
Figure 12.2. User CRC card
But we are getting a bit ahead of
12.4. Finding the Objects
The basic technique for doing OOA  with CRC cards is to start with a stack of blank cards. Assemble a design team (this may be one person, or this may be dozens).  The first step should always be the nomination of the real-world objects. Don't edit or critique at this point. If someone says "computer" as an object, write "Computer" on the top of a card and put it on the table. If someone says "Manager" write it on a card and put it on the table.
To take our example, suppose we have the following list of CRC cards after such an
Where do you go from here? Let's
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-Exupry: "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  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," "Computer," 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
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
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.