CRC Cards - Naming Part 3

Another way of specifying a class’s name is to use CRC cards. Proposed by Kent Beck and Ward Cunningham¹, I first came across these many years ago in Grady Booch’s book ‘OO Analysis and Design’. CRC initially stood for Class, Responsibilities and Collaborators, though in today’s single responsibility principal world, Responsibilities has been quietly renamed Responsibility. The concept is that you use the cards as part of your design process to determine your system’s key abstractions and their relationships. To use CRC cards, first you need a bunch of... well... cards. The 3 x 5 inch index cards will do. You then divide the card up as shown below:

From the diagram you can see that the card is divided into three areas: the name of the class is prominently placed along the top of the card, its responsibility in the centre and the collaborators that’ll help to fulfill that responsibility at the bottom. This is just my personal preference for laying out a CRC card - I find it easier to fit the text in this way. The original authors split the card vertically and not horizontally as I do.


Note the the original CRC card design only ever contained the three fields: Class, Responsibilities and Collaborators; however, if you look on Wikipedia an additional two fields have been added by the author: SubClasses and SuperClass. Whilst specifying a class’s superclass may be useful, I disagree with adding subclasses. This is because an object should know nothing about its subclasses and its design shouldn’t be influenced by them. Furthermore adding extra information will tend to hide the main benefit of CRC cards.

According to proponents of CRC cards, they’re useful because they allow you map out your application’s design before jumping straight into coding, which is always a good idea. This has the benefit that in mapping a class on a card you’re easily able to discover other classes within your application. Cards can be shuffled, laid out or pinned to walls to outline your application’s key abstractions.

In the example above I’ve written the cards for a scenario where the user has to add their address to the system. This is a simple MVC scenario to demonstrate the relationship between cards/classes.

The next question to ask is are CRC cards still useful or obsolete; after all they are now twenty two years old. I have to say that they probably aren’t that useful; however, they do seem to get mentioned in a good number of OO design books and are popular on the web. If you Google “CRC Cards” you’ll get 7,540,000 results, but have you ever seen any one using them in anger?

I have to stick my hand up now and say that I have in the past CRC cards. You don’t, however, have to use 3 x 5 inch index cards as there is a lot of benefit in simply scribbling out the CRC headings in your note book and adding the responsibility and collaborators next to them. All of which means that it’s now time to reveal a big secret... the cards themselves aren’t really that useful; the most important and useful thing about these cards is the fact that you’re forced to think about and write down an object’s responsibility. This stands to reason: if you can’t define your object’s intent, how can you code it?

Having accurately defined a class's responsibility you now know exactly what it does and why it exists and can therefore review the original name that you chose and, if necessary, come up with something more suitable.

The idea of constantly reviewing the name of a class and comparing it with its responsibility is the key to good object naming.

So, the next question to ask is whether or not there are any guidelines for defining an object’s responsibility? There are, but more on that next time.

---

¹Beck and Cunningham Oct. 1989 A Laboratory for Teaching Object Oriented Thinking - SIGPLAN Notices Vol. 24