Cohesion and Coupling in OO Design

Understanding Cohesion and Coupling in Object‑Oriented Design

In modern software engineering, cohesion and coupling are two fundamental quality attributes that determine how maintainable, testable, and flexible a codebase is. This course breaks down the core concepts, illustrates common pitfalls, and provides practical techniques to improve both cohesion and coupling in your object‑oriented (OO) designs.

What Is Coupling?

Coupling describes the degree of interdependence between classes or modules. The goal is to keep this relationship as loose as possible.

• Tight (or strong) coupling: Classes share implementation details, often creating objects directly or accessing each other's internal state.
• Loose (or weak) coupling: Classes interact through well‑defined interfaces or abstractions, allowing each side to change independently.

Consider the following quiz question:

Which statement best describes the main difference between tight and loose coupling?

• Tight coupling means classes share implementation details, whereas loose coupling relies only on exposed interfaces. (Correct)

This highlights that the essence of loose coupling is interface‑based communication rather than direct knowledge of concrete implementations.

Techniques to Reduce Tight Coupling

One of the most common ways to loosen coupling is to replace direct instantiation with dependency injection—passing collaborators through constructors or setters.

class Subject {
    private Topic topic;
    public Subject(Topic topic) { this.topic = topic; }
    public void startReading() { topic.understand(); }
}

In the quiz, the modification that most effectively reduces tight coupling is:

Replace the direct instantiation with a constructor parameter of type Topic. (Correct)

By injecting Topic, Subject no longer decides which concrete Topic to use, making it easier to swap implementations or mock the dependency in tests.

Understanding Cohesion

Cohesion measures how closely related the responsibilities of a single class are. High cohesion means a class has a single, well‑defined purpose. Low cohesion indicates a class does many unrelated things, which often leads to maintenance headaches.

From the quiz:

Which of the following class designs exemplifies high cohesion?

• class Accounts { void getStaffSalary(); … } class Personnel { void getStaffDetails(); … } (Correct)

Here, each class focuses on a distinct domain concept—salary handling vs. personnel details—resulting in clear responsibilities.

Signs of Low Cohesion

• Methods that perform unrelated tasks (e.g., parsing dates, sending emails, and calculating taxes in the same class).
• Large “God” classes that aggregate many responsibilities, such as a class containing salary calculation, staff details, and sales reporting.
• Frequent changes to a class because new features are added that do not belong to its core purpose.

Quiz example of a drawback:

A class contains methods for salary calculation, staff details, and sales reporting. (Correct)

Why High Cohesion Matters

High‑cohesion classes are easier to understand, test, and maintain. They tend to change less often because new functionality is added in new, appropriately scoped classes rather than expanding existing ones.

What is the primary benefit of designing classes with high cohesion?

• They become easier to maintain and less frequently changed. (Correct)

Common Cohesion Violations

Consider a Ghost class where a method changeState() calls three unrelated helper methods. This violates high cohesion because the method performs multiple distinct tasks.

In the Ghost class example, why is the changeState() method considered a violation of high cohesion?

• It calls three other methods, thereby performing multiple distinct tasks. (Correct)

Transforming Tight Coupling into Loose Coupling

The most direct way to achieve loose coupling is to program to an interface rather than a concrete class.

interface Logger { void log(String msg); }
class FileLogger implements Logger { /* ... */ }
class Service {
    private Logger logger;
    public Service(Logger logger) { this.logger = logger; }
    public void doWork() { logger.log("work done"); }
}

Which change would most directly convert a tightly coupled design into a loosely coupled one?

• Introduce an interface that the dependent class implements and program to that interface. (Correct)

Real‑World Example: Box and Volume

In a scenario where a Volume class directly accesses a public field volume of a Box class, the coupling is tight because Volume depends on the internal representation of Box.

In the Box and Volume example, which statement best explains why the coupling is considered tight?

• Volume directly accesses Box's public field 'volume', making it dependent on Box's internal representation. (Correct)

A better design would expose a method like Box.getVolume() or, even more abstractly, use a Shape interface that both classes implement.

Practical Checklist for Improving Cohesion and Coupling

• Ask yourself: Does this class have a single responsibility?
• Prefer constructor injection over creating objects inside the class.
• Program to interfaces or abstract classes, not concrete implementations.
• Keep fields private and expose behavior through methods.
• Use design patterns such as Strategy, Dependency Injection, and Facade to separate concerns.

Summary

Mastering cohesion and coupling is essential for building robust OO systems. By ensuring each class does one thing well (high cohesion) and interacts with others through abstractions (loose coupling), you create code that is easier to test, extend, and maintain.