CRC Cards: An Agile Thinking Tool
- Using CRC Cards for Interactive Design
- Where Should Details Go?
- CRC Cards Can Be Used as Lightweight Documentation
- Can CRC Cards Fit with TDD?
- References
- Author Bio
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This year marks the 20th anniversary of the World Wide Web and the CRC card. I know you know about the web. But you should also know about CRC cards. Kent Beck and Ward Cunningham introduced CRC cards— Class-Responsibility-Collaborator cards—in 1989 as a tool for teaching object-oriented thinking. Since then, CRC cards have moved far beyond the classroom. They can be useful in short design sessions or for interactively telling design stories. Written into a design document or summarized on a wiki, they can also present a high-level, conceptual design overview.
I prefer using 4 by 6 inch lined index cards. They give me enough room to write without feeling cramped. By convention, the name of the class or design element is written at the top, responsibilities on the left 2/3 of the card, and collaborators listed the right (a collaborator is another name for a helper). But don’t be misled by the name—while the first C stands for class, but you can also use CRC cards to describe responsibilities of components, subsystems, services, or interfaces.
It’s interesting to compare the original CRC cards written by Kent Beck and Ward Cunningham that describe the Model-View-Controller pattern with the CRC cards in Patterns of Software Architecture (Bushmann et al, 1996):
|
Beck and Cunningham MVC Cards: |
POSA MVC Cards: |
 |
 |
 |
 |
 |
 |
Beck and Cunningham’s cards say somewhat less; the POSA cards somewhat more. Whatever is written is brief and to the point. You could never write code directly from any these cards. Like agile story cards, CRC cards are intended to spur conversation. CRC cards are used for design conversations.
In fact, nothing prevents you from drawing design doodles or rough sketches on a card—whatever it takes to get your ideas across. A CRC card minimalist might lay down cards one-by-one, write the briefest note on each, and then use them to tell a story.
In the POSA book, CRC cards introduced the roles played by elements in a pattern. While POSA cards contain more details than Beck and Cunningham’s, they still only provide a gentle introduction. They are followed by sequence diagrams and nuanced pattern discussions.
The POSA descriptions contain more implementation details than I prefer. They state that a View “creates and initializes its associated controller” and “implements the update procedure”. These days many frameworks offer other ways to associate views with controllers and to refresh views. So I prefer leaving out implementation details, especially when they can be found elsewhere. In fact, I’d rather state that a View “renders the model” instead of “implements update”.
Of course, I don’t want to be too picky, either. If someone understands an object’s purpose after reading its responsibility statements, they are good enough.
Using CRC Cards for Interactive Design
In Designing Object-Oriented Software (Wirfs-Brock et al, 1990) I popularized the use of CRC cards for modeling object collaborations. I suggested that the scope of a modeling session might be a use case or a path through a use case. These days I find that agile teams often use CRC cards when designing a particularly challenging user story or important interactions for a small set of objects. Not every user story (or use case) warrants a modeling session. But when you are covering new ground, it can useful to think a bit before coding. CRC cards can be part of any short design discussion. While sketching out design ideas, you can note responsibilities on CRC cards. In practice, it can be hard to keep CRC cards and sequence diagrams up to date in real time. While you focus on interactions, you ignore responsibilities; and while you think about responsibilities, collaboration details slide. But both perspectives are useful. So I find jot down important bits on CRC cards—even after I’ve sketched out collaborations.
We slightly updated the CRC card format in Object Design: Roles, Responsibilities and Collaborations (Wirfs-Brock and McKean, 2003). We suggested that you could flip the card over and write a simple purpose statement and assign a role stereotype (a design element can be a controller, coordinator, service provider, interfacer, structurer or information holder). In practice, most find it easier to make these annotations once they’ve decided on responsibilities. Writing a purpose statement helps you check that your class’ responsibilities are cohesive. If they aren’t, it’s hard to write a simple purpose statement.