Interface Segregation Principle (ISP) — small focused interfaces
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
The Interface Segregation Principle says clients should not be forced to depend on operations they do not use. The interface should be shaped around a coherent capability required by its consumers, rather than becoming a catalogue of everything one implementation can do.
For example, a robot may implement Workable, while a human worker implements both Workable and Breakable. A broad Worker interface containing work, eat, and sleep would force the robot to expose methods that have no valid meaning. Focused contracts let each consumer and implementation use only the capability it understands.
ISP does not require one method per interface. The boundary is useful when clients, implementations, or change reasons differ. Too many microscopic interfaces can add noise, so the goal is a small coherent contract, not the smallest possible file.
Interface Segregation Principle (ISP) — small focused interfaces
Direct Answer
The Interface Segregation Principle says clients should not be forced to depend on operations they do not use. Prefer focused contracts shaped around client capabilities instead of one broad interface for every consumer. A class may implement several small interfaces when it genuinely provides several capabilities.
Code Example
// Violates ISP: fat interface forces all implementors to handle everything
interface Worker {
void work();
void eat();
void sleep();
void attendMeeting();
}
class Robot implements Worker {
public void work() { /* actual work */ }
public void eat() { throw new UnsupportedOperationException("Robots don't eat"); }
public void sleep() { throw new UnsupportedOperationException("Robots don't sleep"); }
public void attendMeeting() { /* can do this */ }
}
// ISP-compliant: split into focused interfaces
interface Workable { void work(); }
interface Eatable { void eat(); }
interface Sleepable { void sleep(); }
interface Meetable { void attendMeeting(); }
class Human implements Workable, Eatable, Sleepable, Meetable {
public void work() { /* work logic */ }
public void eat() { /* eat logic */ }
public void sleep() { /* sleep logic */ }
public void attendMeeting() { /* meeting logic */ }
}
class RobotWorker implements Workable, Meetable {
public void work() { /* work logic */ }
public void attendMeeting() { /* meeting logic */ }
// No forced eat() or sleep() methods
}
Common Mistakes & Pitfalls
- Splitting by method count: group operations that clients use as one coherent capability.
- Using default methods as a substitute for design: a default can ease compatibility, but clients still see the method.
- Making one interface per class automatically: start from consumer needs, not a naming convention.
- Forgetting the client view: an implementation may use a larger internal API while exposing a focused application contract.
Check your understanding
Answer these without looking back at the article.
- How does ISP relate to the Single Responsibility Principle?
- What is a fat interface?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.