Interface Segregation in Practice

The fix is to split the fat interface into focused ones and let implementors pick the pieces they need. The caller that only needs printing depends on Printer, and the caller that needs both depends on a combined interface built from the two focused ones.

public class Main {
    public static void main(String[] args) {
        SimplePrinter p = new SimplePrinter();
        p.print("hi");
        MultiPrinter m = new MultiPrinter();
        m.print("hi");
        m.scan();
    }
}

interface Printer {
    void print(String text);
}

interface Scanner {
    void scan();
}

interface PrintScan extends Printer, Scanner { }

class SimplePrinter implements Printer {
    public void print(String text) { System.out.println("print: " + text); }
}

class MultiPrinter implements PrintScan {
    public void print(String text) { System.out.println("print: " + text); }
    public void scan() { System.out.println("scanning"); }
}

The output shows the practical benefit. The simple printer implements one method and never has to pretend it can scan. The multi printer implements the combined contract and does both. The interfaces are arranged so that existing callers that only printed still compile, because the print method kept its name and signature in the narrowed interface.

The general rule behind this is the interface segregation principle: prefer many small, specific interfaces over a few large ones, so that clients depend only on what they use. A client that implements an interface it does not fully support is forced into empty methods or exceptions, which is a signal that the contract is too wide.

The cost is real and should be acknowledged. Splitting an interface that is already published is a breaking change, because the combined type no longer exists and existing implementations stop satisfying the old contract. In a live codebase you would keep the old interface extending the new focused ones, so the combined contract still exists and existing implementations still compile.

The principle says clients should not be forced to depend on methods they do not use. A well-designed interface is small and cohesive, and a class implements only the interfaces that describe capabilities it actually has.

A fat interface causes three kinds of damage. Implementors must write methods they have no use for, and they fill them with empty bodies or exceptions, so the class carries code that is a lie. Clients that depend on the whole interface are coupled to methods they never call, so any change to those methods ripples outwards. And because the interface grows, the number of classes forced to change with it grows too.

A common symptom is an implementation whose methods throw an unsupported operation exception. That exception is a marker that the contract asked for more than the class could honestly provide, and it is the moment to split the interface rather than to add another exception.

The fix is to look at the actual callers. If every caller uses only a subset of the methods, split the interface around those subsets. If different callers use different subsets, that is exactly the evidence that there are several small contracts hiding inside one large one.

You let it implement several small interfaces and give each one a focused meaning. A class that can print, scan and fax implements Printer, Scanner and Faxer. Callers that need printing depend only on Printer, and the class is free to grow a fourth capability without touching the printing contract.

The composition trick helps here. If the capabilities are not all implemented by the same object, the class can hold collaborators and implement the interfaces by delegating. A multifunction printer that owns a scanner and a fax module implements the three interfaces and forwards to the right collaborator.

The judgement call is whether the capabilities belong together. If a class only implements an interface because it has to fill in methods it does not support, the capability does not belong to it. That is the point at which you should ask whether the class should be split, or whether the caller is asking the wrong object to do the job.

One practical warning is about interface inheritance. If a large interface extends many small ones, every implementor of the large one must implement them all, so the segregation only helps callers who depend on the small ones directly. The combined interface is still useful for callers that genuinely need the whole set, but it must not be the only one in the design.