Techniques to Identify ISP Violations

Every ISP smell reduces to one mechanical fact: an interface is a compile-time contract that a class must satisfy in full before the compiler will let it exist — so the moment an interface bundles a method some implementer cannot honestly fulfill, the language forces that implementer to either lie (a stub that throws) or pollute its public surface with a method it never wanted, and every caller that depends on the interface inherits the false promise. The techniques below are not four unrelated checklist items; they are four observable shadows of that single failure. The skill is learning to read each shadow back to the contract that cast it.

The one mechanism, four shadows

An interface I with methods {m1…mn} says: any reference of type I may receive any of m1…mn, and the type system guarantees a sensible answer. A class C implements I is the compiler-enforced promise that C backs all of them. ISP is violated exactly when that promise is partially false for some C. You cannot see "partial falseness" directly, so you hunt for the artifacts it leaves behind:

One thing that is deliberately not on this list: "low cohesion." A low-cohesion interface is not a fifth, independent test — it is the fat-interface smell described from the producer's side, so it collapses into row two. The mechanically distinct, callable tests are the four above, and each one traces straight back to "the contract promised more than an implementer can keep."

Worked trace: from a green compile to a production NPE

Take the classic over-wide contract. A real implementer, a real caller, and we follow concrete values through the type system.

// The over-wide contract: it bundles three independent capabilities.
interface MultiFunctionDevice {
    String print(String doc);   // printers + MFPs
    byte[] scan();              // scanners + MFPs
    void fax(String number);    // fax machines + MFPs
}

// A cheap office printer. It can print. It cannot scan or fax.
class BasicPrinter implements MultiFunctionDevice {
    public String print(String doc) {
        return "printed: " + doc;
    }
    public byte[] scan() {                       // forced stub #1
        throw new UnsupportedOperationException("BasicPrinter cannot scan");
    }
    public void fax(String number) {             // forced stub #2
        throw new UnsupportedOperationException("BasicPrinter cannot fax");
    }
}

// A caller that only needs to scan-then-archive. It does not care about print/fax.
class ArchiveJob {
    void archive(MultiFunctionDevice dev) {      // over-wide parameter type
        byte[] image = dev.scan();               // line A
        store(image);
    }
    void store(byte[] b) { /* ... */ }
}

Now trace one concrete run: new ArchiveJob().archive(new BasicPrinter()).

Why the naive version is wrong: the stubbed scan()/fax() are not "defensive" — they convert a type error (this object should never have been accepted where scanning is required) into a runtime error. The compiler would have caught it for free if archive had asked for the narrow type Scanner instead. Stubbing throws away the one guarantee the type system was offering.

The fix and what it buys you

Split the welded contract into the capabilities that actually vary independently, then let each caller demand exactly the slice it uses.

interface Printer { String print(String doc); }
interface Scanner { byte[] scan(); }
interface Fax     { void fax(String number); }

// BasicPrinter now implements ONLY what is true of it. No stubs exist.
class BasicPrinter implements Printer {
    public String print(String doc) { return "printed: " + doc; }
}

// An MFP composes the capabilities it genuinely has.
class OfficeMfp implements Printer, Scanner, Fax {
    public String print(String doc) { return "printed: " + doc; }
    public byte[] scan() { return new byte[]{ 0x1, 0x2 }; }
    public void fax(String number) { /* dial + send */ }
}

class ArchiveJob {
    void archive(Scanner dev) {        // narrow type: only scanners get in
        store(dev.scan());
    }
    void store(byte[] b) { /* ... */ }
}

Re-run the trace: archive(new BasicPrinter()) now fails at compile time — BasicPrinter is not a Scanner. The bug moved from a 2 a.m. production exception to a red squiggle in the editor. That is the entire payoff of ISP made concrete: violations become uncompilable instead of merely untested. (Go reaches the same end with implicit, tiny interfaces — io.Reader, io.Writer — where a function asking for io.Reader simply will not accept a type lacking Read; the segregation is the idiomatic default rather than a refactor.)

Pitfalls

• Reading a stub as politeness, not evidence. A throwing override looks like a courteous "not supported" message. It is actually a confession that the type is too wide. Every UnsupportedOperationException in an override is a failed ISP test you should chase to its interface.
• Mistaking UnsupportedOperationException for an LSP-only smell. It signals both: LSP because a subtype weakens the supertype's promise, ISP because the promise was over-wide to begin with. On this page it is an ISP detector; fixing it via segregation also fixes the LSP breakage for free.
• Over-segregating into one-method interfaces everywhere. Splitting a genuinely cohesive contract (e.g. List's add/remove/get) into single-method interfaces yields dozens of types every collection must juggle. Segregate by capabilities that vary independently across implementers, not by method count.
• Default methods hiding the smell. Java default bodies and abstract base classes that throw let you keep the fat interface while suppressing the stub at each site. The over-wide contract is still there; you've just moved the lie to one place and silenced the compiler's complaint.
• Capability flags as a substitute for types. boolean canScan() plus if (dev.canScan()) reproduces the runtime-deferral failure exactly — callers now must remember to check, and forgetting is a production bug, not a compile error.

When to segregate — and when not to

Decision signal: segregate when implementers of a contract form distinct subsets over its methods — some classes use {print}, others {scan, fax} — and callers likewise depend on different slices. If you can draw two implementers whose used-method sets don't overlap, the interface should split along that boundary.

The trade-off you are buying:

Versus the Adapter alternative: when the fat interface is third-party and you cannot split it, wrap it in a narrow Scanner adapter you own; your code depends on the slim type while the adapter absorbs the fat dependency. You gain the compile-time guarantee at the cost of one wrapper class and a layer of indirection.

One-liner: choose segregation when implementers and callers use different subsets of the methods and you want wrong usage to be uncompilable; prefer a single interface when every implementer genuinely backs every method (it is truly cohesive) and splitting would only multiply types without removing a single stub.

Takeaways

• All four smells are one fact: an interface is a full contract, and a violation is a contract an implementer can only partially keep — the stub, the fat type, the instanceof check, and the shotgun edit are its visible shadows.
• The detector that compiles fastest in your head: a throwing or empty override is a failed ISP test — trace it back to the over-wide interface.
• ISP's payoff is concrete, not aesthetic: segregation moves "wrong object used here" from a runtime exception to a compile error, exactly where it is cheapest to fix.
• Segregate along capabilities that vary across implementers — not by method count — or you trade a fat interface for interface confetti.

Sources: Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices (the original ISP and the Xerox printer case) and Clean Architecture; the Java Language Specification on interface implementation and dynamic dispatch; and the Go standard library's io.Reader/io.Writer as the canonical small-interface idiom.