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.

The Single Responsibility Principle (SRP) is defined by wikipedia as every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.

Although the origins of this concept are someone disputed, most believe it was originally developed by Tom DeMarco in his book Structured Analysis and Systems Specification but was later popularized by Robert Martin in his book Agile Software Development: Principles, Patterns, and Practices. The principle simply states that a given class should have one and only one responsibility. And that the behavior of the class should be narrowly aligned with that single responsibility.

The essence of this concept has to do with the reason to change a class. If a class has more than one responsibility, it may have different reasons to change, each of which are independent of one another. Take for example a class that both imports data from a file and saves the data to a persistent storage mechanism. The single class needs to be modified for any change to the incoming file format as well as any change to the underlying data storage mechanism structure. These changes should not be connected. By modifying the class to adjust the file format, you risk introducing a bug to the file persistence code. In a hurry, without the safety net of automated unit tests (gasp!), developers tend to only test code that is related to a given change.

If your classes follow SRP, you probably can get away with only testing related code (although thorough automated unit tests are always the best course of action). If you violate SRP, you need to be extra cautious when considering the ripple effect from changes to your code. I believe SRP is so fundamental that it can make the difference between a system that is easy to maintain and one that is your worst nightmare to maintain.

Sounds simple right? Well it is, but it is common while designing and refactoring to find SRP violations. But let’s face it. Most software stinks and I have seen countless convoluted designs. Many of these designs (not designed by me of course) had a systemic SRP issue. SRP in one class in your system is not big deal, but SRP in most of your classes is sure recipe for disaster and a system that is very difficult to maintain.

When I have difficulty getting a design to feel right, I try to ask myself whether the classes in that portion of the system are following SRP. Many times, I find the core design issue stems from one or more classes with more than one responsibility.

There are many ways to deal with SRP violations. The most common are:

1. Delegation - To put behavior in another class and leverage a pattern such as Strategy
2. Aggregation - To push the behavior out to another class and reference this new class

Regards,
Matt