The interface segregation principle: A fun and simple guide

What is interface segregation?

The interface segregation principle (ISP), one of the five SOLID principles of object-oriented design, states that no client should be forced to depend on methods it does not use. When developers follow this principle, they create small, specific interfaces for different parts of a program rather than one large interface for everything. This helps keep the application code clean and easy to work with.

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 exactly what the interface segregation principle (ISP) is designed to avoid. It teaches developers and architects to keep things simple and focused -- just like how Alex should have separate remotes for each device instead of a complicated all-in-one.

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

Let's look at a basic example of how ISP can be violated. The following code describes operation of several appliances and lighting in a house:

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
    }
}

In this example, the SmartLight class implements an Appliance interface that has methods unrelated to a light, including brewCoffee and cleanRoom. This is a clear violation of ISP because the light doesn't need those methods to perform its required function.

Let's fix this issue by using ISP, as so:

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");
    }
}

We now have separate interfaces for different functionalities. The SmartLight class only implements the Switchable interface, as its focus is only to turn on and off. This revised design adheres to ISP because it keeps interfaces small and relevant.

When to use ISP

When designing interfaces for your software, if a class only uses a portion of an interface, it's a sign that the interface might need to be split. Applying ISP achieves the following 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.

In summary, the interface segregation principle helps you design better, more focused interfaces that keep your code tidy and efficient. If only Alex kept his remotes so simple.

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.