Interface segregation

A Logger interface starts small: log(message). Over time it grows to include rotate(), compress(), sendAlert() and flush(). A simple ConsoleLogger now must stub out four methods it will never use, and every new method added to Logger is a breaking change for every logger in the codebase.

The problem

1 // This interface grew from one method to five. Every implementor
2 // must now implement or stub all five — even ConsoleLogger.
3 class Logger {
4   log(msg)       { throw new Error("not implemented"); }
5   rotate()       { throw new Error("not implemented"); }
6   compress()     { throw new Error("not implemented"); }
7   sendAlert(msg) { throw new Error("not implemented"); }
8   flush()        { throw new Error("not implemented"); }
9 }
10 class ConsoleLogger extends Logger {
11   log(msg) { console.log(msg); }
12   // rotate, compress, sendAlert, flush: useless stubs.
13 }

Adding archive() to Logger breaks every class that extends it — including ConsoleLogger, which has nothing to do with archiving.

The rule

Interface segregation principle: clients should not be forced to depend on methods they do not use. Split one fat interface into several small, role-specific interfaces.

Each small interface describes one capability. A class implements the interfaces it genuinely supports. A caller depends only on the interface it uses.

In code

When to split and when not to

ISP costs one interface name per role. That name is the abstraction boundary and should represent a real domain concept: Writable, Rotatable, Alertable. Splitting for its own sake produces LoggerWritingCapability and similar monstrosities.

The practical test: if adding a method to an interface requires changing a class that has nothing to do with the new method, the interface is too fat.

Where you have already seen it

Java 8's Iterable, Comparable, and Closeable are each one method. Runnable is one method. The standard library avoided one large Object interface precisely because callers want to depend on exactly the capability they need. Node's stream.Readable and stream.Writable are separate for the same reason.