Balancing Collaboration and Cohesion

There’s no such thing as a perfect CRC model — not in practice, not even in theory. The truth is, every design decision you make about collaboration creates trade-offs. You can’t reduce coupling without touching cohesion, and you can’t improve cohesion without rethinking who talks to whom. That’s the real challenge: building a model that’s flexible, readable, and maintainable, not just technically correct.

CRC design cohesion isn’t about making every class do one thing. It’s about ensuring that when classes work together, they do so for a clear, shared purpose. Too much coupling, and your model becomes brittle. Too little collaboration, and you end up with isolated, underused classes. The sweet spot lies in mindful design — where responsibilities are meaningful, and interactions feel natural, not forced.

What you’ll learn here is how to spot when your model is drifting toward fragmentation or entanglement. You’ll gain practical strategies to keep your CRC design modular, resilient, and aligned with real-world behavior. This isn’t about memorizing rules — it’s about spotting patterns, fixing drift, and making decisions with confidence.

Understanding the Two Sides of CRC Design

What Is Cohesion in CRC?

Cohesion measures how well a class’s responsibilities support a single, unified purpose. A high-cohesion class has responsibilities that directly relate to its role. For example, a BankAccount class that manages deposits, withdrawals, and balance checks has strong cohesion.

Low cohesion appears when responsibilities don’t belong together — like if the same class handled both user authentication and interest rate calculations. This suggests the class is doing too much, or its purpose is unclear.

High cohesion is not about minimizing responsibilities. It’s about aligning them so that each one supports the class’s central intent.

What Is Coupling in CRC?

Coupling refers to how tightly classes depend on each other. High coupling means one class knows too much about how another works — for instance, calling internal methods, relying on specific data structures, or assuming a particular design.

Low coupling means classes interact through well-defined, stable interfaces. They don’t care how the other works — only what it does.

Consider a PaymentProcessor that accepts a Payment object and sends it to a BankingService. If the processor assumes the banking service uses a specific database schema, it’s tightly coupled. If it only calls a processPayment() method, it’s loosely coupled.

Striking the Balance: Class Collaboration Balance

Every design must balance cohesion and coupling. You can’t optimize one without impacting the other. The key is to focus on modular CRC design — where classes are cohesive, and their interactions are clear and minimal.

Here’s how to approach this balance step by step.

Step 1: Start with a Clear Purpose

Ask: What is this class for? If you can’t answer in a single sentence, the class likely lacks cohesion.

Example: A ReportGenerator should generate reports. If it also manages user permissions or handles file storage, it’s doing too much. Split it into ReportGenerator, UserAccessControl, and FileStorageManager.

Step 2: Refactor Based on Responsibility Overlap

When multiple classes share responsibilities, ask: Do they belong together, or do they serve different domains?

Use the Single Responsibility Principle as a guide. If responsibilities are related to the same actor or process, they might belong under the same class. If not, consider separation.

Step 3: Minimize Direct Dependencies

Avoid direct references to implementation details. Instead, depend on abstractions.

Instead of:

class ReportGenerator {
    void sendToBank(BankAccount account) {
        // accesses account.balance directly
    }
}

Prefer:

class ReportGenerator {
    void sendToBank(PaymentService service) {
        // only knows it needs to use service
    }
}

This reduces CRC coupling and improves flexibility.

Step 4: Prioritize Communication Over Complexity

Certain collaborations are inevitable. A Customer must interact with an Order, and an Order must connect to a Product. But how?

Use clear, high-level concepts: “Customer places Order” is better than “Customer calls Order’s addProduct()” — the latter creates tighter coupling.

Let the collaboration focus on intent, not implementation.

Practical Guidelines for Modular CRC Design

Here are four habits I’ve seen work consistently in real-world CRC sessions.

• Start with actors and workflows. Model from business events — not from code. Let the user story or process guide your class roles.
• Use domain language in responsibilities. Say “calculate interest” instead of “perform calculation.” This keeps cohesion tied to meaning.
• Review collaboration paths after adding each class. Ask: Is this interaction necessary? Can another class handle it?
• Set a “cohesion threshold” for your session. If a class has more than 3–4 responsibilities, pause and ask: Are these truly about the same intent?

When to Split a Class

Use this checklist to decide if a class needs splitting.

Indicator	Sign of Problem
More than 4 responsibilities	High risk of low cohesion
Responsibilities span different domains	Signs of mixed concerns
One responsibility depends on a method in another class	High CRC coupling
Refactoring leads to code duplication	Class may be doing too much

If two or more indicators apply, consider splitting the class.

Real-World Example: A Hospital Appointment System

Let’s say you’re modeling a hospital system. A Appointment class initially holds:

• Set patient ID
• Set doctor ID
• Set date and time
• Calculate fee based on doctor level
• Send confirmation email

The fee calculation and email sending are unrelated to appointment scheduling. This is low cohesion and high coupling.

Refactor:

• Appointment: handles scheduling, date/time, patient/doctor assignment
• AppointmentPricer: calculates fees based on doctor level
• EmailService: sends confirmation

Now, Appointment is cohesive, and dependencies are minimal and well-defined.

Common Pitfalls and How to Avoid Them

Over-Collaborating: The “Everything Talks to Everything” Trap

When every class calls every other, you’re building a spaghetti model. That’s high coupling and poor cohesion.

Solution: Step back. Ask: Who is responsible for this action? If only one class should manage the process, let it own the logic — don’t spread it out.

Under-Collaborating: The “I’ll Do It All” Class

One class taking on every task isn’t a solution — it’s a design failure.

Solution: Use the “if it feels like a second role, it probably is” rule. If a class starts handling tasks from multiple domains, split it.

Ignoring Communication Patterns

Just because two classes need to talk doesn’t mean they should. Sometimes, a third class — a coordinator or coordinator pattern — handles the interaction.

Example: Order and Inventory don’t need direct access. A StockManager can validate and reserve stock, reducing direct coupling.

Frequently Asked Questions

How do I know if my CRC model has good cohesion?

If all responsibilities in a class support a single purpose, and no major changes in behavior are needed when adding new features, you’re likely on the right track.

Is low coupling always better than high coupling?

No — some coupling is necessary. The goal is controlled coupling. You want minimal, intentional dependencies. Not zero. Some coupling is required for the system to function, but it should be visible, stable, and changeable without ripple effects.

Can I achieve high cohesion without reducing collaboration?

Yes. High cohesion doesn’t mean no collaboration. It means the collaboration is intentional and driven by a shared purpose. Good collaboration doesn’t destroy cohesion — poor collaboration does.

What if my team insists on keeping a class with many responsibilities?

Present the trade-offs: increased bug risk, longer testing cycles, difficulty refactoring. Use metrics like “number of responsibilities” and “number of classes it calls” to demonstrate coupling and cohesion visually. Show how splitting improves maintainability over time.

How do I teach CRC design cohesion to beginners?

Start with a simple, relatable example — like a bakery, library, or classroom. Let them write responsibilities in natural language. Then, ask: “Does everything here belong to the same role?” Use red pens to mark responsibilities that don’t fit. This builds intuition before introducing theory.

Should I use CRC coupling and cohesion metrics in every model?

Not for every model — but yes, in every team project. Use them as a conversation tool, not a scorecard. The goal is alignment, not perfection. A CRC model is a conversation starter — not a final artifact.