It seems the excitement and use of Class, Responsibility, Collaboration (CRC) cards has diminished over the years. But with an emphasis on agile development approaches, it seems there is a rise in simple, yet powerful approaches that are low tech. The barrier to entry for CRC cards is pretty low…you just need a pile of 3″x5″ or 4″x6″ index cards and a pen.

Are CRC big upfront design? I don’t think so, but it is a potentially conflicting with Test Driven Development (TDD). I see the greatest value of CRC cards as a way to get a sense for the initial high-level design and not a way to work through the design of every low-level class in a system. This may be most useful in the case of a service oriented system, for example, where you may desire a bit of focus up front on the exposed external interface. Or better yet, a way to talk through a design if you get “stuck”. The downside of CRC cards is that you are not keeping a client-oriented view like you do when using TDD. A client-oriented view is critical to good design and is one of the natural advantages to TDD.

Back to CRC cards…The idea is that each physical index card represents a single class or interface. Each card should have the name of the class at the top, the class responsibility (note that conscious choice to make this singular) on the bottom left and the classes with which the given class collaborates on the bottom right.

CRC Card

I like the smaller 3″x5″ cards because you want to be constrained by space. If you write your class responsibility (typically captured as bullets) and you find that you are running out of room on your card because it is requiring too many bullets, you have already identified that you are likely violating the SRP and you need to break the class up into separate classes or at least rethink your design. If you run out of space for your collaborations, you also likely have an issue.

I like to arrange the cards physically on a table so they are arranged close to their collaborators. The process is typically done with a pair or group of developers and involves a lot of discussion as the cards are created and modified. The cards are a jumpstart mechaims, and like many other artifacts in an agile project, they will be discarded and the software will take on a life of its own.