Class–Responsibility–Collaboration Card¶
A compact object-design card naming a class, its responsibilities and its collaborators for scenario-based discussion and revision.
Core Idea¶
A class–responsibility–collaboration (CRC) card is a compact object-design representation. Each card names a class or object role, lists what it should do in short active phrases, and names collaborators it needs. Designers arrange the cards and play through scenarios to discover missing, misplaced or overloaded responsibilities.[^ref-0e098e39beb9]
The card is a selective sketch. It does not contain full code, prove runtime messages or guarantee a good design. Beck and Cunningham used physical index cards and found handling them useful for teaching. A digital card may keep the three informational fields, but their original paper does not establish equal teaching effects.[^ref-0e098e39beb9]
Scope of Application¶
CRC cards support both explanation of an existing object design and development of a proposed one. The necessary roles are: an independently describable object-design target; a distinct named-card medium; responsibility and collaborator fields mapping selected roles to that medium; a known limit on fidelity; and scenario-based interpretation or revision. For a new design, the target is the requirements and intended interactions, not an already implemented architecture.[^ref-0e098e39beb9]
Clarity¶
Ask what problem the object-design target addresses. On each card, state the role's duties and the other roles whose help it needs. Walk through a concrete event: which card handles each action, which collaborator is involved, and where does an unassigned duty appear? Add, reword or split cards when the scenario exposes a gap. A collaborator name is a proposed relationship, not proof of a particular message call.[^ref-0e098e39beb9]
Manages Complexity¶
A few short fields keep attention on responsibilities instead of syntax and implementation. Cards can be moved, overlapped and rewritten while participants test an interaction. The compression also omits details that later specifications or code must settle. The paper reports classroom and design experience, but no controlled effectiveness study or deployed banking-system outcome.[^ref-0e098e39beb9]
Abstract Reasoning¶
Treat the design as a network of local commitments. Give each role responsibilities, identify collaborators, then trace a relevant scenario across the cards. If the chain breaks, revise the proposed assignments and replay it. The strict parent Representation applies because an object-design target is selectively mapped to an interpretable card medium with known limits and operational use. That mapping also retains the live parent's inherited Abstraction role; the card's object-specific fields keep this entry domain-specific.[^ref-0e098e39beb9]
Knowledge Transfer¶
The three-field role structure travels from interpreting Smalltalk-80 MVC to sketching an automatic banking machine, while the object names and implementation details differ. One use explains an existing framework; the other develops a proposed device/database/interface design. Transfer the responsibility and collaborator mapping and the scenario practice, then justify the target and assumptions anew.[^ref-0e098e39beb9]
Example¶
Smalltalk-80 Model–View–Controller¶
The authors' Figure 2 places Model, View and Controller cards to help explain an existing framework. View and Controller overlap and appear above Model; only some responsibilities are shown. Mapped roles: existing object design → target; named cards → medium; duties and collaborator entries → selective mapping; deliberately partial coverage → fidelity limit; placement and discussion → interpretation.[^ref-0e098e39beb9]
Automatic banking-machine exercise¶
In a teaching exercise, the paper's appendix sketches Account, Transaction, Dispenser, CardReader, RemoteDataBase, Event, Action and Screen roles. Mapped roles: intended machine interactions and requirements → target; classroom cards → medium; assigned duties and collaborators → mapping; provisional sketch rather than implementation → fidelity limit; scenario walkthrough → use. This is a proposed design exercise, not a deployed bank.[^ref-0e098e39beb9]
Relationships to Other Abstractions¶
Current abstraction Class–Responsibility–Collaboration Card Domain-specific
Parents (1) — more general patterns this builds on
-
Class–Responsibility–Collaboration Card is a kind of Representation Prime
A CRC card selectively represents an object-design target through named responsibility and collaborator fields.
Hierarchy path (1) — routes to 1 parentless root
- Class–Responsibility–Collaboration Card → Representation → Abstraction
Neighborhood in Abstraction Space¶
Class–Responsibility–Collaboration Card sits in a sparse region of the domain-specific corpus (99th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2551 abstractions)
Nearest neighbors
- Goal Modeling — 0.75
- Prototype-based programming — 0.75
- Design Practice — 0.75
- Class (Knowledge Representation) — 0.75
- Programming Class — 0.75
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
- UML class diagram: overlapping class vocabulary does not automatically include CRC's duty, collaborator and scenario roles.
- Single-responsibility principle: the original cards can hold several duties.
- Executable implementation: a card suggests assignments but cannot prove actual behavior.
- Guaranteed improvement: the original reports experience, not a universal measured effect.[^ref-0e098e39beb9]
References¶
[^ref-0e098e39beb9]: Kent Beck and Ward Cunningham (1989), A Laboratory For Teaching Object-Oriented Thinking, OOPSLA 1989 Conference Proceedings and SIGPLAN Notices 24(10), §§2–5, Figures 1–2 and Appendix. Full author-hosted original paper.