The Core Idea: Classes, Responsibilities, and Collaborations

About 8 out of 10 teams I’ve worked with initially misplace responsibilities or overuse collaboration, not because they lack skill, but because they misunderstand how classes, responsibilities, and collaborations interact. It’s not about writing code—it’s about thinking in roles. A class isn’t just a container; it’s a role player with duties and relationships.

When you grasp CRC modeling correctly, you’re no longer chasing syntax. You’re building a shared understanding of how objects work together. This chapter breaks down the three pillars: class, responsibility, and collaboration. Each is essential—and none can stand alone.

The Three Pillars of CRC Modeling

Class: The Identity of an Object

A class is more than a name—it’s a role. It represents an entity in your system with a distinct identity and purpose.

For example, in a library system, Book isn’t just a data container. It’s a role: “holds information about a published work.” The name defines the job, not the data.

When defining a CRC class, ask: What real-world object or concept does this represent? Is it a noun? Can multiple instances exist? These questions clarify the class definition.

Responsibility: What the Class Must Do

Responsibilities are duties—what the class *must* do to fulfill its role. They’re not methods; they’re actions the class is responsible for.

Consider Loan in a library system. Its responsibilities might include:

• Track the check-out date
• Calculate due date
• Record late fees
• Notify when overdue

Each responsibility is a verb phrase, concise and focused. Avoid vague terms like “manage” or “handle.” Instead, use precise, actionable language.

Good responsibilities are measurable. If you can’t test whether a class “has” a responsibility, it’s too broad. A responsibility like “update borrower status” lacks clarity—“check if borrower is overdue” is better.

Collaboration: Who Helps, and How

Collaboration defines who the class works with to fulfill its responsibilities. It’s not about inheritance or inheritance—this is about interaction.

Take Loan again. To calculate due date, it may need to collaborate with DueDateCalculator. To notify the user, it may collaborate with NotificationService.

Modeling collaborations means identifying the *other classes involved* in achieving a responsibility. Use simple names. No need for UML notation here—just clear labels.

Collaborations should be minimal and meaningful. If a class depends on five others to do one small task, you likely have a design smell. Re-evaluate responsibilities—perhaps they’re too fragmented.

How the Three Work Together

Let’s walk through a real example: a BankAccount system.

Class: BankAccount

Responsibilities:

• Track current balance
• Accept deposits
• Process withdrawals
• Apply monthly interest

Collections:

• Collaborates with TransactionLogger to record each deposit or withdrawal
• Collaborates with InterestCalculator to compute monthly interest
• Collaborates with AccountManager to validate account status

Notice how no single class holds all the logic. The BankAccount focuses on managing its state and core behaviors. Other classes handle specialized tasks. This is separation of concerns through collaboration.

The key insight: a class’s responsibilities are defined by its role, and its collaborations are the tools it uses to fulfill them.

Best Practices for CRC Card Elements

Creating effective CRC cards isn’t about perfection—it’s about clarity and alignment. Here are proven techniques:

1. Start with nouns, then verbs: Identify real-world objects first. Then ask: What do they do?
2. Use active verbs: “Calculate”, “store”, “notify”, “validate”—not “has”, “is”, or “manages”.
3. One responsibility per line: Avoid combining tasks. “Process and record transaction” is two actions.
4. Keep collaborations simple: List only classes directly involved. Avoid abstract or generic names like “system” or “manager”.
5. Revisit and refactor: After the first pass, ask: Can any responsibilities be moved to better classes? Is collaboration necessary?

These aren’t rules—they’re habits that lead to better design.

Modeling Collaborations with Real Intent

I’ve seen teams list collaborations like “works with database” or “uses the backend.” That’s not collaboration—it’s abstraction. Real collaboration is about *roles*, not technology.

Ask: What role does the other class play? What does it offer? For example:

Collaboration	Role	Why It Matters
NotificationService	Sends email alerts	Ensures the account doesn’t act as a messaging engine
InterestCalculator	Applies interest rate logic	Separates business logic from account state
TransactionLogger	Records financial events	Enables audit trails without cluttering the account

This table isn’t just a list—it’s a design decision. Each collaboration supports a specific responsibility and reduces coupling.

Common Challenges and How to Fix Them

Even experienced teams stumble. Here are the most frequent issues and how to overcome them:

• Overloaded responsibilities: A class like User listing “manage profile”, “send messages”, “handle login”, “track preferences” is a red flag. Split into ProfileManager, MessageService, etc.
• Missing or vague collaborations: If a class needs to “notify” someone, name the actual collaborator: NotificationService, not “the system”.
• Too many collaborations: More than 3–4 collaborators per class often shows fragmentation. Reassess if responsibilities are properly grouped.
• Collaboration without purpose: If a class collaborates but doesn’t use the other’s output, the collaboration is likely unnecessary.

These aren’t errors—they’re signals. They mean something in the design is misaligned.

From CRC Cards to Real Code

There’s no magic leap from CRC cards to code. But there’s a clear path.

Each responsibility becomes a method. Each collaboration becomes a dependency or method call. For example:

public class BankAccount {
    private double balance;
    private final InterestCalculator interestCalculator;
    private final TransactionLogger transactionLogger;

    public void deposit(double amount) {
        balance += amount;
        transactionLogger.log("Deposit", amount);
    }

    public void applyMonthlyInterest() {
        double interest = interestCalculator.calculate(balance);
        balance += interest;
    }
}

The CRC card guided this design. The code implements it.

Don’t expect to write code from the card. Use the card to design the intent. Then write code that matches.

Frequently Asked Questions

What makes a good responsibility on a CRC card?

A good responsibility is specific, measurable, and verb-driven. It describes an action the class is accountable for. Examples: “Calculate due date”, “Validate email”, “Send notification”. Avoid vague terms like “manage” or “handle”.

How many collaborations should a class have?

Two to four is ideal. More than four suggests the class may be doing too much or responsibilities are poorly grouped. Re-evaluate responsibilities—can any be moved to another class?

Can a class have no responsibilities?

No. Every class must have at least one responsibility. A class with no responsibilities has no reason to exist and likely represents a design gap.

Should I use CRC cards for every system?

Not always. They’re most useful in early design, especially for new teams or complex domains. For simple systems, you may skip them—but never skip thinking in responsibilities.

How do CRC cards help in team collaboration?

CRC cards create a shared language. They make roles and interactions visible to everyone—developers, testers, product owners. This reduces miscommunication and aligns teams around design intent.

Do I need to use UML to benefit from CRC modeling?

No. CRC cards are a standalone modeling tool. You don’t need UML to use them. But they’re excellent for building UML class diagrams later—because the relationships and responsibilities are already mapped.