CRC Cards

The three regions of a card

Every CRC card has the same layout. The class name goes across the top. The left column lists responsibilities — the things this class knows (data it holds) or does (operations it performs), written as short verb phrases like "calculate total" or "hold line items." The right column lists collaborators — the other classes this one must talk to in order to meet its responsibilities. Responsibilities and collaborators usually line up: a responsibility on the left that needs help from another class names that class on the right.

┌─────────────────────────────────────────────┐
│  Order                              (Class)  │
├──────────────────────────┬──────────────────┤
│  Responsibilities        │  Collaborators   │
├──────────────────────────┼──────────────────┤
│  • hold the line items   │  OrderLine       │
│  • calculate the total   │  OrderLine       │
│  • know the customer     │  Customer        │
│  • request payment       │  Payment         │
└──────────────────────────┴──────────────────┘

Notice how each responsibility on the left maps to a collaborator on the right. "Calculate the total" can't be done alone — Order has to ask each OrderLine for its subtotal — so OrderLine appears as a collaborator. That two-column pairing is what turns a vague class name into a concrete, testable role.

Brainstorm the cards as a group

You start by reading a use case and pulling out the nouns as candidate classes — Customer, Order, Product, Payment — and writing each on its own physical card. Then, with the team gathered around the table, you hand the cards out and assign responsibilities by asking, for each thing the system must do, "whose job is this?" The cards are cheap and movable on purpose: anyone can pick one up, cross something out, or tear it up and start over. Because everyone can see and touch the deck, the whole group designs together instead of one person at a whiteboard.

The heart of it: role-play a scenario

The real magic isn't writing the cards — it's enacting a scenario with them. You pick a concrete use case ("a customer checks out their cart") and walk it step by step. For each step, you ask "which card is responsible for this?", physically pick up that card, and act as if you are that object. To do the step, the object almost always needs help — and the moment you say "to total the order, I ask each line for its price," you've discovered a collaborator. You point from the active card to the cards it talks to, and those arrows become the relationships in your design.

Walking the scenario this way surfaces three things at once: missing responsibilities (a step nobody's card can do), missing classes (a step that needs an object you forgot to create), and the collaboration graph (who calls whom). It's a dry run of the system performed by people holding cards — and it finds design holes far faster and cheaper than writing code would.

Too many responsibilities is a smell

As you role-play, watch the cards. If one card keeps getting picked up for everything and its responsibility list overflows the index card, that's a God class forming — low cohesion, too many reasons to change. The fix is to split it: peel some responsibilities onto a new card and hand them off. This is exactly the Single Responsibility Principle and high cohesion you met earlier, now made physical: the size of the card is your cohesion budget.

A low-cost precursor to diagrams

CRC is deliberately informal. There's no rigorous notation, no tool, no version control — just cards you're happy to throw away. That cheapness is the point: you can explore three different decompositions in the time it would take to draw one careful class diagram. Once the deck stabilizes and the scenarios run cleanly, the cards translate almost directly into a UML class diagram (cards → classes, responsibilities → methods/fields, collaborators → associations) and the role-play steps into a sequence diagram.

When CRC cards earn their keep

Reach for CRC at the start of design, right after you have use cases but before any diagrams or code. It shines when a group needs to agree on a decomposition quickly — onboarding people onto an existing design, exploring an unfamiliar domain, or settling an argument about who should own a responsibility. Because the cards are throwaway, it's ideal precisely when you're unsure and want to try several shapes cheaply.

It's less useful once the design is settled and detailed — at that point a real class diagram, sequence diagram, and code carry the weight. CRC is a discovery tool, not a system of record; don't try to make the cards authoritative or keep them in sync forever.