Interface Segregation Principle (ISP)

Medium

In plain terms

The Interface Segregation Principle says that no client should be forced to depend on methods it does not use. If you have a huge interface with many methods, classes that implement it might only need a few—but they still have to implement or stub the rest. That leads to fat interfaces and awkward implementations.

Split the interface into smaller, role-specific ones. A printer might implement Printable and Scannable separately so a client that only prints does not depend on scan. Small interfaces keep dependencies minimal and make it easier to add new implementations.

What you need to know

•No forced dependency on unused methods
•Small, focused interfaces
•Clients depend only on what they use

Example

Code is language-agnostic in spirit; adapt the idea to your language:

// Bad: one big interface
// interface Worker { work(); eat(); sleep(); }

// Good: segregated
// interface Workable { work(); }
// interface Eatable { eat(); }
// Robot implements Workable only
// Human implements Workable, Eatable, Sleepable

Why this matters

ISP comes up when discussing API design and fat interfaces. Interviewers ask how you avoid forcing clients to depend on methods they do not use.

How it connects

Small interfaces make DIP easier (depend on narrow abstractions). It supports SRP at the interface level: each interface has one cohesive purpose. Composition often uses multiple small interfaces instead of one big one.

Interview focus

Be ready to explain these; they come up often.

▸Clients should not depend on methods they do not use. Split large interfaces.
▸Example: Robot implements Workable, not Worker (which has eat, sleep).
▸Benefit: fewer unnecessary dependencies; easier to mock and test.

Learn more

Dive deeper with these resources:

TutorialsPoint