SOLID principles
intermediateInterface Segregation Principle (ISP)
Clients should not be forced to depend on methods they do not use.
The Interface Segregation Principle says that clients should not be forced to depend on methods they do not use. Many small, role-specific interfaces are better than one large, general-purpose one, because a class should only have to know about the operations it actually needs. A "fat" interface couples every implementer and every caller to methods that may be irrelevant to them.
Power tools don't all need the same controls. A drill has trigger + reverse; a vacuum has on/off + suction-level. One universal control panel forces every tool to deal with buttons it doesn't have.
Key Concepts
1
The classic violation is a sprawling interface that bundles unrelated capabilities — a Worker interface with work(), eat(), and sleep(), or a Machine with print(), scan(), and fax(). A RobotWorker forced to implement eat(), or a simple printer forced to implement fax(), ends up with methods it cannot meaningfully support, usually stubbed to throw UnsupportedOperationException — which is also an LSP violation. Segregating the interface into focused roles — Workable, Eatable, Sleepable, or Printer, Scanner, Fax — lets each class implement exactly the capabilities it has, and lets each client depend only on the slice it uses. A multifunction device can still implement all three; a basic printer implements just one.
Workerwork()eat()sleep()Machine
2
The benefits compound with the rest of SOLID. Narrow interfaces reduce coupling, so a change to the fax contract cannot ripple into classes that only print; they make mocking and testing easier because a test only needs to stand up the small role it exercises; and they make implementations honest, since a class no longer advertises behaviour it doesn't have. The interview-level nuance is recognising the smell — implementers throwing on methods, or callers depending on an interface far broader than what they touch — and knowing that the fix is to split by client role, not arbitrarily by method count.