The interface segregation principle helps developers design APIs whose clients depend only on the operations they actually need. The result is usually smaller interfaces, fewer unnecessary dependencies and code that is easier to change without affecting unrelated classes.
What is interface segregation?
The interface segregation principle (ISP), one of the five SOLID principles of object-oriented design, states that clients should not be forced to depend on methods they do not use. In practice, that means designing interfaces around the needs of their clients instead of creating one large, general-purpose interface that every implementation must satisfy.
To better understand how ISP works, try this analogy: a multifunction remote control that's so complex and convoluted that it's lost control.
The tale of the multipurpose remote
Imagine you have a friend named Alex who loves gadgets. One day, Alex buys a multipurpose remote that claims to control everything in his house: the TV, lights, air conditioner, coffee maker and robotic vacuum. Sounds amazing, right?
But there's a catch. Every time Alex turns on the TV, he also accidentally brews coffee and starts the vacuum. He adjusts the air conditioner, and the lights change colors like a disco. The complex, cluttered remote control ends up causing chaos.
This is the kind of unnecessary coupling ISP is designed to prevent. In software terms, Alex's remote exposes one oversized contract to clients that need only a small subset of its capabilities.
ISP as task-specific remote controls
To continue that analogy, think of ISP as different remote controls for each gadget in the home. Instead of one remote that does everything (and gets confusing), each remote has just the buttons required for a task. Each part of the overall system only uses what it needs and isn't cluttered with unnecessary extra features.
What happens when ISP isn't followed? A simple example
Consider an oversized Java interface that combines unrelated capabilities for lights, coffee makers, vacuum cleaners and music players:
interface Appliance {
void turnOn();
void turnOff();
void brewCoffee();
void cleanRoom();
void playMusic();
}
class SmartLight implements Appliance {
@Override
public void turnOn() {
System.out.println("Light is on");
}
@Override
public void turnOff() {
System.out.println("Light is off");
}
@Override
public void brewCoffee() {
// Not applicable
}
@Override
public void cleanRoom() {
// Not applicable
}
@Override
public void playMusic() {
// Not applicable
}
}The SmartLight class is forced to implement brewCoffee(), cleanRoom() and playMusic() even though those operations have nothing to do with a light. The empty methods are a strong design smell: the interface is making this client depend on capabilities it does not need.
The solution is to split the broad contract into focused capability interfaces:
interface Switchable {
void turnOn();
void turnOff();
}
interface CoffeeMaker {
void brewCoffee();
}
interface Cleaner {
void cleanRoom();
}
interface MusicPlayer {
void playMusic();
}
class SmartLight implements Switchable {
@Override
public void turnOn() {
System.out.println("Light is on");
}
@Override
public void turnOff() {
System.out.println("Light is off");
}
}Now SmartLight implements only Switchable, the capability it actually provides. A coffee machine could implement Switchable and CoffeeMaker, while a robotic vacuum could implement Switchable and Cleaner. The interfaces can be composed according to each class's real responsibilities.
class SmartCoffeeMachine implements Switchable, CoffeeMaker {
@Override
public void turnOn() {
System.out.println("Coffee machine is on");
}
@Override
public void turnOff() {
System.out.println("Coffee machine is off");
}
@Override
public void brewCoffee() {
System.out.println("Brewing coffee");
}
}This is an important detail about ISP: the goal is not simply to make every interface tiny. The goal is to create cohesive interfaces that match what their clients actually require.
When to use ISP
If an implementation repeatedly contains empty methods, throws UnsupportedOperationException for interface methods, or depends on only a small portion of a large interface, the contract may need to be split. Applying ISP can provide several benefits:
- Simplify your code. To reduce complexity, ensure classes only implement what they need.
- Enhance flexibility. Make it easier to change or extend functionality with no impact to unrelated components.
- Improve maintainability. Keep your codebase clean and easy to understand.
Interface segregation is ultimately about controlling dependencies. Design contracts around cohesive client needs, compose multiple interfaces when a class genuinely provides several capabilities, and avoid forcing implementations to support methods that do not belong to them. Alex can keep the universal remote, but your Java classes do not need one.
Ashik Patel is an associate full-stack developer with a background as a back-end developer and API developer. He has worked with various programming languages and frameworks, including Java, JavaScript, Go and Python.