Coupling and Cohesion

Coupling measures how much one class depends on another. Cohesion measures how closely the responsibilities inside one class belong together. Good design aims for low coupling and high cohesion: classes depend on each other through narrow contracts, and each class does one job well.

public class Main {
    public static void main(String[] args) {
        Report r = new Report(new PlainFormatter());
        r.addLine("alpha");
        System.out.println(r.render());
    }
}

interface Formatter {
    String format(String line);
}

class PlainFormatter implements Formatter {
    public String format(String line) { return line; }
}

class Report {
    private final Formatter formatter;
    private final java.util.List<String> lines = new java.util.ArrayList<>();
    Report(Formatter formatter) { this.formatter = formatter; }
    void addLine(String line) { lines.add(line); }
    String render() {
        StringBuilder sb = new StringBuilder();
        for (String line : lines) {
            sb.append(formatter.format(line)).append("\n");
        }
        return sb.toString();
    }
}

The report class shows both. It is cohesive, because everything it does is about producing a rendered report. It is loosely coupled, because it depends on the formatter interface rather than on a concrete formatting class. The plain formatter can be replaced with one that upper-cases, prefixes or emits markup, and the report class does not change.

The alternative to look at is the same class hard-coding a formatter. Then the report knows about the concrete class, cannot be tested with a fake, and has to be edited when the output format changes. That is higher coupling, and the change ripples outwards.

These two goals pull against each other in one place. Splitting a class to reduce coupling can create classes that each do too little, and cohesion suffers. The way to resolve it is to split along responsibilities rather than along arbitrary lines, so each new class has a reason to exist and a single thing it is about.

Low cohesion shows up as a class with unrelated methods. If a class has a method that formats output, another that opens a database connection, another that parses a date and another that computes a total, it is a collection of functions that happen to share a file. The test is whether you can describe the class in one sentence without using the word and.

Tight coupling shows up in the dependencies. If a class instantiates its collaborators directly, reads their internal fields, or refers to their concrete types in its signatures, it is tightly coupled. The smell to look for is a constructor whose body is full of new expressions, because each one is a dependency the class cannot avoid and cannot substitute.

Other signals of tight coupling are long parameter lists that pass a dozen values through to another layer, and a class that changes whenever an unrelated library changes. Signals of low cohesion are long methods with several unrelated sections, and switch statements over unrelated kinds of thing.

The refactoring moves are standard. Inject the collaborators so you can substitute them, and split the class along its responsibilities so each piece has one job. Then check the result: does each class have a sentence that describes it, and does each dependency go through an interface or a constructor parameter?

Because they are the leading indicators of how expensive the next change will be. Tight coupling means one change ripples through many classes, so the cost of a modification grows with the size of the codebase. Low cohesion means the class has no single responsibility, so the change has to be made in several unrelated places inside one file, and there is no obvious home for the new code.

They also make testing possible. A class that constructs its own collaborators cannot be tested without those collaborators, so its tests either need a real database or a network, which makes them slow and flaky. A class that receives its collaborators can be given fakes, so the test exercises the real logic with none of the infrastructure.

The third benefit is comprehension. Highly cohesive classes have names that describe them, and a reader can navigate a codebase by following the class names rather than by reading every method. That is a large saving for the many people who will read the code and did not write it.

The honest counterpoint is cost. Restructuring to reduce coupling is real work, and for a codebase that will never change it is not worth doing. The threshold is usually whether the system is expected to evolve and whether more than one team touches it. The mistake to avoid is applying the principles reflexively rather than as a means to an end, since over-splitting a cohesive class into fragments produces neither coupling nor cohesion benefits, just navigation overhead.