Interface Segregation Principle Explained with Java Example

Interface Segregation Principle (ISP)

The I in the SOLID principles stands for the Interface Segregation Principle. By the end of this chapter, you'll be able to confidently answer:

1. What is the Interface Segregation Principle?

2. Why do we need it? (What problems arise if we don’t follow it?)

3. How do we apply it in real-world code?

What is the Interface Segregation Principle?

It means that a class shouldn’t be forced to implement methods it doesn’t use.

In other words, don't dump a bunch of unrelated responsibilities into one interface. Instead, break it into smaller pieces so that classes only pick what they actually need.

Let’s look at an example where this principle is violated

interface RestaurantWorker {
    void cook();
    void serve();
    void washDishes();
}

Here, we have one big interface RestaurantWorker with three methods: cook, serve, and washDishes.

But not every restaurant worker does all of these tasks! For example, a chef shouldn’t be serving or washing dishes. Let’s see what happens:

class Chef implements RestaurantWorker {
    public void cook() {
        System.out.println("Cooking food...");
    }
 
    public void serve() {
        // ❌ Not a chef’s job!
        throw new UnsupportedOperationException("Chef doesn't serve food.");
    }
 
    public void washDishes() {
        // ❌ Not a chef’s job!
        throw new UnsupportedOperationException("Chef doesn't wash dishes.");
    }
}

As you can see, all classes are forced to implement methods they don’t actually need. This makes the code messy and harder to maintain.

How to Achieve the Interface Segregation Principle

To fix this, we should split the big interface into smaller ones, so each class only implements what it needs.

Let’s do that:

Chef Duties

interface ChefDuties {
    void cook();
}

DishWasher Duties

interface DishwasherDuties {
    void washDishes();
}

Waiter Duties

interface WaiterDuties {
    void serve();
}

Now, each class has only the relevant responsibilities, and they’re not being forced to do something they shouldn’t. The code is cleaner, shorter, and more focused.

This is exactly what the Interface Segregation Principle is all about: keeping things separate and meaningful.

Confusions: LSP vs ISP

Many people get confused between Liskov Substitution Principle (LSP) and Interface Segregation Principle (ISP). Here’s an answer from Jon Reid on StackOverflow that should help clear things up:

LSP: A subclass must respect the contract of the parent class.

ISP: A class should only use the methods it actually needs from an interface.

How they fit together:

• LSP: When a subclass overrides a method from the parent, it must do so without breaking the original contract. This means it shouldn’t throw exceptions or change the method’s behavior unexpectedly.

• ISP: The goal is to split large interfaces into smaller, more specific ones. This way, subclasses only have to implement the methods that are relevant to them.

Even after you apply ISP, the methods in the subclass should still follow the parent class's intended behavior, as LSP requires.