Class–Responsibility–Collaboration Card¶

A compact object-design card naming a class, its responsibilities and its collaborators for scenario-based discussion and revision.

Version: v1 · 2026-10-07 · History
Domain-specific #: 13833
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Object Oriented Design → Computer Science & Software Engineering
Aliases: CRC Card

Core Idea¶

A class–responsibility–collaboration (CRC) card is a compact way to think through an object design. One card names a class or object role, states its responsibilities in short active phrases, and names other objects whose help it needs. Designers arrange cards and walk through scenarios, asking which card handles each needed action and where a missing or overloaded responsibility belongs.^[1]

The card is a selective design representation. It records intended object roles and interactions, not executable code, a complete interface contract or proof that the system works. Beck and Cunningham originally used physical index cards and valued the bodily interaction. A digital card with equivalent fields may preserve the representational identity, but their paper does not establish equal teaching effects for digital use.^[1]

Structural Signature¶

Object-design target: an existing design to explain, or independently describable requirements and intended interactions for a proposed design.
Named card unit: a manipulable entry for a class or object role, on paper or an equivalent medium.
Responsibilities: concise active phrases identifying problems that role should solve, without pretending to list every future method.
Collaborators: other named roles whose services or control participate in fulfilling those responsibilities. A collaborator entry is an intended design relation, not proof of a particular runtime message.
Mapping and fidelity: class names and the two fields map selected target roles to the card; omitted code and behavior are known limits of the sketch.
Scenario interpretation: participants use card positions, discussion and what-if enactment to inspect or revise assignments.^[1]

Remove responsibilities and collaborators and the card becomes a name-only inventory. Remove the target-to-card mapping and a three-column note merely resembles the layout. A static list can preserve some information, but it does not carry the original scenario-driven method in full.

What It Is Not¶

A CRC card is not a UML class diagram; a diagram may emphasize inheritance or attributes without the card's responsibility and collaborator roles. It is not the single-responsibility principle: the original cards can list several responsibilities and their relationships. It is not proof of high cohesion, low coupling or implementation correctness. The original automatic banking-machine example was a teaching design exercise, not a deployed bank system or a measured quality improvement.^[1]

The closest near miss is a class inventory naming related classes but never stating what each should do or testing their interactions through a scenario. It shares object vocabulary, but the responsibility and use roles are absent.

Scope of Application¶

The method arose in object-oriented design education and explanation. Beck and Cunningham describe cards for both making a new design and understanding an existing one. Their paper moves from a HyperCard stack to physical index cards, explicitly retaining class, responsibility and collaborator information while finding physical arrangement useful for group reasoning. Those media choices are evidence about their practice, not a formal requirement that every valid CRC representation be exactly four by six inches.^[1]

A card can be written before implementation. In that case its target is the independently described requirements and intended object interactions, not a completed class architecture invented after the fact. Interpretation depends on the participants' convention for the three fields and the scenarios they choose. A finished stack of cards alone may be hard for an outsider to read without that context; the authors report such a case.^[1]

Clarity¶

For a proposed card, ask: Which design problem or existing object arrangement is it representing? What does its named object take responsibility for? Which other objects must collaborate? Walk through one concrete scenario and point to the card that handles each step. When no card owns a needed action, add or revise a responsibility or introduce a new role. When one card grows unwieldy, reword or redistribute the responsibilities, as the original authors describe.^[1]

Do not read a collaborator name as a guaranteed software dependency. It is a working assignment that later design and code must refine. A card is faithful to its stated scope when it helps participants recover the intended roles and known omissions, not when it predicts every method call.

Manages Complexity¶

The three fields suppress code syntax and implementation detail so participants can reason about object roles. Separate cards make assignments spatially manipulable: a team can move, overlap, add or split roles while tracing a scenario. This helps expose missing interactions, but compression can hide constraints that must be specified elsewhere. The original paper reports teaching experience and a partial documentation case; it does not present a controlled experiment proving universal design gains.^[1]

Abstract Reasoning¶

Treat a design as a network of local commitments. For each proposed class, state what it is meant to solve and which other roles it asks for help. Simulate a situation from requirements or an existing system; trace a chain of responsibilities and collaborators. If the chain fails, revise the cards and replay the scenario. The method does not imply that every future scenario has been covered. Its value depends on the scenarios' relevance and the accuracy of the role assignments.^[1]

The strict parent is Representation: an object-design target is mapped to a distinct card medium through an explicit convention, with partial fidelity and a use in discussion. The banking case requires special care because its target is proposed requirements and intended interactions, not an already built system. That distinction preserves the live parent's target, medium, mapping, fidelity, use and interpretation roles, together with inherited Abstraction.

Knowledge Transfer¶

The same three-field role test can help read Smalltalk-80 MVC or sketch an automatic banking machine because both are object-design questions. Their workflows differ: one interprets an existing framework, while the other proposes responsibilities for a device, database and interface. The specific class names, programming language and hardware do not transfer automatically. What travels is the practice of recording named responsibility and collaboration assignments and probing them with scenarios.^[1]

Examples¶

Reading Smalltalk-80 Model–View–Controller¶

Beck and Cunningham's Figure 2 puts cards for Model, View and Controller in an arrangement that conveys interaction: View and Controller overlap and sit above Model. The authors deliberately show only part of each object's responsibilities, using the cards to explain an existing user-interface framework rather than to reproduce its code.^[1]

Mapped roles: target → existing MVC object arrangement; medium → named cards; mapping → responsibility and collaborator phrases for Model, View and Controller; fidelity → deliberately partial; use and convention → overlap and placement support a shared design reading. The card arrangement does not imply that every runtime message is depicted.

Designing an automatic banking machine¶

In a teaching exercise, participants design objects for a banking machine. The paper's appendix gives a sample solution with Account and Transaction, device-facing Dispenser and CardReader, RemoteDataBase, and Event, Action and Screen roles. The independently described task is to handle a machine's devices, central bank communication and user interface; the cards sketch proposed object assignments for that task. The exercise is not evidence of an implemented banking system.^[1]

Mapped roles: target → intended machine interactions and requirements; medium → participants' cards; mapping → names, duties and collaborators across banking, device and interface roles; fidelity → provisional design rather than complete implementation; use and convention → scenario walkthrough reveals missing or overburdened assignments. This is unlike the MVC case because it develops a proposed design instead of interpreting an existing framework.

Structural Tensions¶

Compact roles versus omitted detail. Short card phrases make responsibilities easier to move and discuss, while necessarily leaving method contracts, data formats and execution behavior for later work. In the paper, the MVC cards are deliberately partial and the bank-machine appendix supplies a fuller sample, but neither establishes a universal optimum card length. Diagnostic: Can participants recover the intended role and collaboration from this card for the scenario at hand, and which omitted detail must now be specified elsewhere?^[1]

Structural–Framed Character¶

CRC cards sit between a reusable representation structure and a strongly human design practice. The class/responsibility/collaborator fields are recognizable across object systems; the quality of their assignments depends on the requirements and designers' interpretation. The method arose in late-1980s object-oriented teaching and the authors' physical card practice; that origin explains its tactile conventions without making one medium logically constitutive. “Useful” is an evaluative claim that needs a stated task and evidence, not a consequence of having three fields. A digital copy may recognize the same informational structure, while a generic three-column worksheet imports the label if it lacks object responsibilities and scenario reasoning. Its character: a selective object-design representation whose meaning is enacted and revised through shared scenarios.^[1]

Structural Core vs. Domain Accent¶

The portable skeleton is a target represented in a distinct medium through selected fields, stated fidelity and operational interpretation. That supports the strict subsumption / kind_of edge to live Representation because the full parent signature is satisfied. The domain-specific core adds class or object roles, concise responsibilities, collaborators and scenario-based revision. MVC, banking hardware and the exact card size are accents, not identity requirements.

The named CRC entry does not clear the Prime bar: if object roles, their duties and collaborators are stripped out, the method becomes a much broader representation or brainstorming practice. A future substrate-neutral prime would need unlike nonsoftware instances with the same necessary roles and consequences, not merely a visual analogy to cards.

This entry is a kind of Representation.

Strict parent — Representation: the card medium conveys selected design roles under a three-field convention and supports scenario reasoning.
Inherited Abstraction: retaining duties and collaborators while omitting code is a selective simplification, not a promise of complete fidelity.
Related — Decomposition: a team may split an overloaded card, but splitting is a design move, not the definition of a CRC card.^[1]

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 (99^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2551 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

Object implementation: a CRC card suggests responsibilities, not executable methods.
UML class diagram: overlapping vocabulary does not establish the card's three fields and enactment practice.
Single-responsibility principle: CRC does not require exactly one duty per class.
Deployed bank case: the cited banking machine is a classroom design exercise.
Digital teaching equivalence: role information can be reproduced digitally, but equal tactile or teaching effects were not established in the original paper.^[1]

References¶

[1] 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. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p