Introduction to the Interface Segregation Principle

The Interface Segregation Principle works by making the type system enforce capability: an interface is a compile-time contract, so the smaller and more focused each interface is, the fewer methods a class is forced to define and the fewer methods a caller is allowed to call — which means a class can only ever promise behaviour it can actually deliver. Robert C. Martin's original phrasing: "Clients should not be forced to depend on methods they do not use." The leverage point is the word forced: in a statically-typed language, implements Printer is a promise to honour every method on Printer, and the compiler will not let you opt out. So a fat interface manufactures lies — methods that exist only to satisfy the compiler and then betray the caller at runtime.

The fat-interface trap, traced

You are asked to model a fleet of office printers. The tempting move is one interface that names every capability any device might have:

public interface Printer {
    void printDocument(String document);
    void scanDocument(String document);
    void faxDocument(String document);
    void stapleDocument(String document);
}

Now a cheap BasicPrinter — which can only print — is still required by the compiler to supply scanDocument, faxDocument, and stapleDocument. It has nothing real to put in them, so it fakes them:

public class BasicPrinter implements Printer {
    @Override public void printDocument(String document) {
        System.out.println("Printing: " + document);
    }
    // The compiler FORCES these three. The hardware has no scanner,
    // no fax line, no stapler, so the only "honest" body is a lie:
    @Override public void scanDocument(String document) {
        throw new UnsupportedOperationException("BasicPrinter cannot scan.");
    }
    @Override public void faxDocument(String document) {
        throw new UnsupportedOperationException("BasicPrinter cannot fax.");
    }
    @Override public void stapleDocument(String document) {
        throw new UnsupportedOperationException("BasicPrinter cannot staple.");
    }
}

Why the naive version is wrong

The type says BasicPrinter is a Printer and Printer says it can scan — so the type is asserting something false. The failure is not the exception itself; it is that the false promise is invisible until runtime. Trace what happens to an office-automation routine that accepts the wide type:

At step 3 the compiler is useless — it green-lights a call that cannot succeed, because the contract BasicPrinter signed claims scanning is available. The whole point of static typing (catch the error before it ships) has been thrown away. ISP fixes this upstream: if scan is not on the type you hold, line 3 will not compile, and the bug can never reach production.

The mechanism in one move

You split the fat Printer into role interfaces, one per capability, and each device implements only the roles its hardware actually supports:

public interface Printable   { void printDocument(String d); }
public interface Scannable   { void scanDocument(String d); }
public interface Faxable     { void faxDocument(String d); }
public interface Stapleable  { void stapleDocument(String d); }

public class BasicPrinter implements Printable {
    @Override public void printDocument(String d) {
        System.out.println("Printing: " + d);
    }
} // no fake methods, no exceptions, nothing to lie about

public class OfficeAllInOne implements Printable, Scannable, Faxable, Stapleable {
    @Override public void printDocument(String d) { /* ... */ }
    @Override public void scanDocument(String d)  { /* ... */ }
    @Override public void faxDocument(String d)   { /* ... */ }
    @Override public void stapleDocument(String d){ /* ... */ }
}

A function that only needs to scan now declares void archive(Scannable s) — and you literally cannot hand it a BasicPrinter. The error that used to surface as a 2 a.m. pager alert is now a red squiggle in the editor. (The full refactor — including how callers compose multiple roles — is the next lesson; here the goal is to see precisely why the move is forced.)

Pitfalls

• "Header interfaces" — one interface per class. ISP says split by client need, not by implementer. If you mechanically give every class its own one-to-one interface, you double your file count and gain nothing, because no two callers share a narrower view. Segregate where a real caller wants a subset, not reflexively.
• Splitting too fine, then over-composing. If a typical device needs five of your eight micro-interfaces, every concrete class sprouts implements A, B, C, D, E and constructors that wire five collaborators. The cure (cohesive role interfaces grouped by how clients use them) can be worse than the disease if each role is a single method nobody uses alone.
• Default methods as a stealth fat interface. In Java/C# you can give an interface a default body that throws or no-ops. This makes the compiler happy and re-creates the exact runtime-lie you were escaping — UnsupportedOperationException in disguise. A default body is only safe when it is a genuine, callable default, never a placeholder for "this implementer can't."
• Capability checks leaking back in. A team that splits the interfaces but keeps calling if (p instanceof Scannable) everywhere has just moved the fat-interface branching into the call sites. Prefer narrow parameter types (Scannable s) so the type selects the capable devices for you.
• It is a static-typing principle first. In a duck-typed language (Python, Ruby) the compiler never enforces the contract, so ISP's payoff shrinks to documentation and protocol-class hygiene — calling scan() on a print-only object fails at runtime either way. Don't oversell ISP's safety guarantee outside statically-checked code.

When to apply ISP — and when not to

Reach for it when you see the concrete smells: a method body that is throw new UnsupportedOperationException or an empty stub; an implementer that uses far fewer methods than its interface declares; two unrelated callers that each touch a disjoint slice of one big interface; or a change to method X forcing recompilation/retesting of classes that never call X (the fat interface couples them). Any one of these means a client depends on methods it does not use.

The trade-off is interface count and indirection. Segregating turns one named type into four; a fully-featured device now reads implements Printable, Scannable, Faxable, Stapleable, and a caller needing two capabilities must accept a composed type (<T extends Printable & Scannable> in Java) or take two parameters. You buy compile-time honesty and decoupling; you pay in more declarations to navigate.

Versus the named alternatives

• vs. one fat interface (the default). Fat interface: fewer types, zero capability honesty — failures move to runtime and unrelated implementers stay coupled. ISP: more types, failures move to compile time. Choose the fat interface only when every realistic implementer truly supports every method (e.g. List: every list can add, get, size).
• vs. abstract base class with default no-ops. A base class lets sub-types skip methods, but it spends your single inheritance slot, leaks shared state, and the skipped methods still exist on the type — the runtime-lie returns. ISP composes freely (a class can implement any number of roles) and keeps capability in the type. Prefer the base class only for shared concrete behaviour, not to dodge unwanted methods.
• vs. runtime capability check (instanceof / feature flags). You keep one fat type and ask "can this object scan?" at the call site. This is strictly weaker: the question is answered at runtime, scattered across callers, and easy to forget. ISP answers it once, in the type system.

The senior call, in one line: choose ISP when implementers legitimately differ in which methods they can honour and you want the compiler to enforce it; prefer one fat interface when the capability set is genuinely uniform across all implementers and extra types would only add noise.

Takeaways

• ISP's mechanism is the type system: a narrow interface is a promise a class can keep, so impossible calls fail to compile instead of failing in production.
• The diagnostic smell is concrete — an UnsupportedOperationException, an empty override, or an implementer using a fraction of its interface means a client depends on methods it does not use.
• Segregate along client need, not one-interface-per-class; the cost is more types and composed signatures, the payoff is compile-time honesty plus decoupling of unrelated implementers.
• The guarantee is strongest in statically-typed languages; default-method placeholders and stray instanceof checks quietly smuggle the fat interface back in.

Sources: Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices (the origin of ISP and the Xerox print-system case that inspired it) and Clean Architecture (2017); the Java Language Specification on interface implementation and intersection types (&); and the standard library's java.util.List / UnsupportedOperationException contract as the canonical fat-interface counter-example. Re-authored and deepened for this guide — the original lesson showed the bloated-Printer smell correctly but stopped at the problem; this version adds the type-system mechanism, a step-by-step runtime-failure trace, an interface-decomposition diagram, pitfalls, and the selection trade-offs against fat interfaces, base classes, and runtime capability checks.