Interface Segregation Principle (ISP)

The smell: a fat interface

A fat interface is one big contract that bundles together methods that don't all belong to every implementer. The classic textbook example is a Worker interface with work(), eat(), and sleep(). That's fine for a human worker — but the day you add a RobotWorker, it's suddenly forced to implement eat() and sleep(), which make no sense for a robot. The robot has to provide something, so it ends up with empty or throwing methods.

The most famous version is the multifunction device. Imagine one interface, IMultiFunctionDevice, with print(), scan(), and fax(). A fancy office PhotoCopier can do all three — great. But a humble SimplePrinter can only print. Because it implements the fat interface, it is forced to provide scan() and fax() anyway — methods it has no hardware for. All it can do is throw:

class SimplePrinter implements IMultiFunctionDevice {
    public void print() { /* real work */ }

    // forced on us by the fat interface — we can't actually do these:
    public void scan() { throw new UnsupportedOperationException(); }
    public void fax()  { throw new UnsupportedOperationException(); }
}

Why a forced stub hurts

• It pollutes every implementer. Every class that implements the fat interface must write all the methods, even the ones it can't do — so the same throwing stubs get copy-pasted everywhere.
• It lies to callers. Code that holds an IMultiFunctionDevice reference thinks it can call scan(). At runtime, on a SimplePrinter, that call blows up. The interface promised something the object can't keep.
• It blocks change. Add a staple() method to the fat interface and every device — even ones with no stapler — must be touched. Small interfaces only ripple to the classes that genuinely care.

The fix: split into role interfaces

Break the fat interface into small role interfaces — one per capability. Printer has just print(). Scanner has just scan(). Fax has just fax(). Now each class implements only the roles it can truly fulfil. A SimplePrinter implements Printer. A multifunction PhotoCopier implements all three — Printer, Scanner, and Fax — because it genuinely does all three. No class is ever forced; no stub ever throws.

Links to LSP and to cohesion

ISP doesn't live alone. Those throwing stubs also break the Liskov Substitution Principle (LSP): a caller holding an IMultiFunctionDevice expects every method to work, but substituting a SimplePrinter makes scan() blow up — the subtype isn't a safe stand-in for the type. Splitting the interface fixes both problems at once.

When to split an interface

Reach for ISP whenever you notice the tell-tale signs: a class implementing an interface with empty bodies, null returns, or throw UnsupportedOperationException; an interface that keeps growing as new, unrelated features arrive; or different clients that each use only a small, different slice of the same big interface. In each case, carve the fat interface into role interfaces grouped by who-uses-what, and let each class implement only the roles it can honestly keep.

Note that “interface” here is broader than the interface keyword. It also means a class's public surface — the set of public methods other code can call — and a role an object plays for a particular client. ISP applies to all three: a class with 30 public methods, where each caller uses only a handful, is just as fat as a 30-method interface, and can be split the same way.