CRC cards and the Alternatives

CRC Cards

One of the most valuable techniques in coming up with a good OO design is to explore object interactions, because it focuses on behaviour.  CRC (class responsibility-collaboration) cards are a highly effective way to do this. 

To use CRC cards, you and your colleagues gather round a table.  Take various scenarios of a particular use case and act them out with the cards (each of which represents an object) picking them up in the air when they are active to suggest how they send messages to each other and pass them around.  In so doing you're creating sequence diagrams in the air, so to speak, that is doing them mentally and visibly rather than laboriously drawing them. 

An important part of CRC thinking is identifying responsibilities.  A responsibility is a short sentence that summarises something that an object should do: an action the object performs, some knowledge the object maintains or some important decisions the object makes.  The idea is that you should be able to take any class and summarise it with a handful of responsibilities. 

The first C refers to class, the R to responsibilities and the second C to collaborators (the other classes that this class needs to work with).  This gives you some idea of the links between classes at a high level.

One of the chief benefits of CRC cards is that they encourage animated discussion among the developers.  When you are working through a use case scenario to see how instances of classes will implement it, the sequence diagrams can be slow to draw.  Usually, you need to consider alternatives; with diagrams the alternatives can take too long to draw and rub out.  With CRC cards, you model the interaction by picking up the cards and moving them around.  This allow you quickly to consider alternatives, and arrive at a set of classes, the instances of which can easily get together and send messages to each other to solve all the scenarios of all the use cases.

As you do all this, you form ideas about responsibilities and write them on the card.  Thinking about responsibilities is important because it gets you away from the notion of classes as dumb data holders and eases the team members towards understanding the higher-level behaviour of each class.  A responsibility may correspond to an operation, to an attribute, or more likely, an undetermined clump of attributes and operations. 

A common mistake is to create long lists of low-level responsibilities.  Doing so misses the point.  The responsibilities should fit easily on to one card.  Ask yourself whether the class should be split up or whether the responsibilities would be better stated by rolling them up into higher level statements. 

Example of a CRC card:

                    Order

Check if item is in stock         Order line
Determine price                      Customer
Check for valid payment           
Dispatch to delivery address

The top of the card is the name of the class.
The left side is a list of responsibilities of the class.
The right side shows other classes with which the class must collaborate to fulfil its responsibilities.

The Alternatives

The alternative to CRC cards is probably to work laboriously with use cases, class diagrams and sequence diagrams.  You'd do something like this: Draw sequence diagrams to show how each scenario of every use case is implemented by objects (taken from the class diagram) getting together to send messages to each other.  You might find when you've drawn your sequence diagrams that the allocation of responsibilities among classes seems to be poor (you can see that visually from inspecting the sequence diagrams; see notes on interaction diagrams on this web site for examples of balanced and unbalanced responsibility allocation).  So it's back to re-draft your classes and then draw another set of sequence diagrams.  This iterative process will eventually lead to a well-designed system, but it will take a lot of drawing and then screwing up sheets of paper into balls and throwing them in the bin, and then grabbing  fresh sheets. 

The CRC route seems to be more flexible and allows ideas to be explored mentally before being committed to paper in the form of diagrams.  You may still have to go through some of the turmoil explained in the previous paragraph but hopefully a lot less of it.

Exercise, to be answered using the above material:

Compare and contrast using CRC cards with the alternatives.

Possible Answer:

A way of NOT (yes not) using CRC cards is by creating a trial class diagram, with duties assigned to the various classes and then having a look at how objects that belong to these classes will collaborate to fulfil the requirements sent down in the scenarios of the use case model.  To see how the objects collaborate, we draw  interaction diagrams (such as sequence or collaboration diagrams), about one for each scenario.  If the interaction diagrams look to be a mess with too many classes having too much to do and some having almost nothing to do except serve as data holders, then we go back to our class model and revise it and go through the whole process again.  Soon we'll be submerged in a mountain of crumpled up paper as attempt after attempt may fail. 

Solution:  CRC cards, this allows us to do mentally, with the help of these 6 by 4 inch index cards what has been just described above.  We tentatively assign responsibilities to classes writing these responsibilities on to the cards in pencil.  We wave the cards around in the air as we think about how objects of these classes will send messages to each other to collectively fulfil user requirements.  By using pencil erasers we may do some reassigning of responsibilities among the classes. 

In the notes above, I've generally used the term sequence diagram.  Of course you can use the other form of interaction diagram, the collaboration diagram if you wish.

A very short summary of some of the points expressed above:

* use cases are composed of scenarios
* class diagrams show the objects in the system
* a sequence diagram (or collaboration diagram) shows how the objects solve a scenario, so one of these per scenario
* drawing draft class diagrams and sequence diagrams is a repetitive, cyclical process
* CRC cards -way of drawing class diagrams (in pencil on card) and drawing sequence diagrams in the air, to speed up the cyclical process in the point described above.  CRC cards are iteratively changed.