Interactive tutorial · ~20 min · play as you read
Design your classes with index cards, not guesswork
Before you open an IDE, there's a faster way to shape a clean object model: Responsibility-Driven Design (RDD), driven by CRC cards (Class–Responsibility–Collaborator). Invented by Ward Cunningham and Kent Beck in the late 1980s, it's a human-oriented worksheet that pulls you out of procedural thinking and into objects. This page is that worksheet — live.
The things in your problem become candidate objects.
The actions become responsibilities living on a class.
Sorting cards reveals hierarchy, collaboration, and coupling.
The one shift RDD forces
Procedural design asks "what steps happen?" RDD asks "who is responsible for what?" You stop writing a giant script and start assigning duties to small, self-respecting objects. Each object should know a little and do a little — and delegate the rest to collaborators.
The noun / verb filter
RDD always starts from a written description — a user story or a paragraph of requirements. You scan the prose with a mental highlighter: nouns are candidate classes, verbs are candidate responsibilities.
Try it. Click any word to cycle it: plain → noun (class) → verb (responsibility) → plain.
Candidate classes (nouns)
Candidate responsibilities (verbs)
Not every noun survives — how do I prune?
price is a field on Product, not a class),
(2) synonyms of a class you already have, or (3) outside your system's boundary (the "weather", the "user's mood").
What's left is your candidate class list. You'll refine it during the card sort.
Knowing vs. doing
Each candidate class has exactly two kinds of responsibility. What it knows (data / attributes) and what it does (behavior / methods). Getting this split right is most of the battle. Sort each statement below into the right bucket.
Click a statement, then click the bucket it belongs in. (On desktop you can also drag.)
Knows (data)
Does (behavior)
The CRC card
Now capture a class on a single 4×6 index card. The format is deliberately tiny — if it doesn't fit on the card, the class is doing too much. Fill one in below. Watch the warning if it starts to bloat.
Responsibilities
Collaborators
Live design coach
Markdown for this card:
The card sort — simulating data flow
The original ritual was physical: developers laid the cards on a table and "walked" a scenario, moving a token from card to card as responsibilities were invoked. Two questions drove the sort:
Similarity → generalization
"Do these objects have strong similarities?" If yes, extract a shared superclass (an is-a hierarchy).
Dependency → collaboration
"Does this object need another to finish its job?" If yes, that other class is a collaborator (a has-a / uses-a link).
Coupling meter. Adjust how many responsibilities two cards hand back and forth. If two cards are "constantly stuck together," that's a smell — the design is too tightly coupled and wants refactoring.
The god-object check
The golden rule that keeps RDD honest is the Single Responsibility Principle: a class should have exactly one reason to change. If you can describe a class only by using "and," it's probably two classes.
Type a one-sentence description of a class. The checker flags the classic "and/also" smell.
Self-check: did it click?
Five questions on the RDD / CRC workflow.
You scored
Ready to design your own system?
This page taught the method on a fixed example. Now take it to a blank canvas: paste your problem statement, auto-extract candidates, build a full deck of CRC cards, detect god objects and tight coupling, and export a Markdown or JSON spec.