Interface Segregation Principle (ISP)

An Overview

The Interface Segregation Principle (ISP) is one of the five SOLID principles of object-oriented design, formulated by Robert C. Martin. The key idea behind ISP is that no client should be forced to depend on methods it does not use. In other words, instead of having a single large interface, it’s better to break it down into smaller, more specific interfaces, each serving the needs of distinct client groups.

This helps prevent “fat interfaces” (interfaces with too many methods), making the system more flexible, maintainable, and less prone to changes that can inadvertently affect unrelated parts of the code.

Key Concepts of ISP

Avoid Fat Interfaces: Large, all-encompassing interfaces force clients to implement methods they don’t need, leading to unused, bloated code.
Client-Specific Interfaces: Each client should have an interface tailored to its specific needs. This results in a clean, modular design where changes in one part of the system don’t affect others.
Better Maintainability and Flexibility: ISP encourages separation of concerns and reduces coupling, making it easier to change or extend functionality without breaking existing code.

Violating ISP: A Common Scenario

To understand ISP better, let’s first look at an example that violates the principle.

from abc import ABC, abstractmethod

# A fat interface
class Worker(ABC):
    @abstractmethod
    def work(self):
        pass

    @abstractmethod
    def eat(self):
        pass

# A normal worker can both work and eat
class HumanWorker(Worker):
    def work(self):
        print(“Human working”)

    def eat(self):
        print(“Human eating”)

# A robot doesn’t eat, but is still forced to implement the method
class RobotWorker(Worker):
    def work(self):
        print(“Robot working”)

    def eat(self):
        # Robot doesn’t eat, but must provide an implementation
        print(“Robot doesn’t need to eat”)

# Client code
def perform_tasks(worker: Worker):
    worker.work()
    worker.eat()

human = HumanWorker()
robot = RobotWorker()

perform_tasks(human)
perform_tasks(robot)

from abc import ABC, abstractmethod

# A fat interface

class Worker(ABC):

@abstractmethod

def work(self):

pass

@abstractmethod

def eat(self):

pass

# A normal worker can both work and eat

class HumanWorker(Worker):

def work(self):

print(“Human working”)

def eat(self):

print(“Human eating”)

# A robot doesn’t eat, but is still forced to implement the method

class RobotWorker(Worker):

def work(self):

print(“Robot working”)

def eat(self):

# Robot doesn’t eat, but must provide an implementation

print(“Robot doesn’t need to eat”)

# Client code

def perform_tasks(worker: Worker):

worker.work()

worker.eat()

human = HumanWorker()

robot = RobotWorker()

perform_tasks(human)

perform_tasks(robot)

In this case, we have a Worker interface with two methods: work and eat. A human worker can both work and eat, but a robot only works—it doesn’t need to eat. However, because of the fat interface, RobotWorker is forced to implement the eat method, which leads to unnecessary and potentially confusing code.

Applying ISP: A Cleaner Design

To apply the Interface Segregation Principle, we can split the Worker interface into smaller, more specific interfaces: one for working and one for eating. This way, the robot only has to implement what is relevant to it, while the human worker can implement both.

from abc import ABC, abstractmethod

# Separate interfaces
class Workable(ABC):
    @abstractmethod
    def work(self):
        pass

class Eatable(ABC):
    @abstractmethod
    def eat(self):
        pass

# A human worker implements both Workable and Eatable
class HumanWorker(Workable, Eatable):
    def work(self):
        print(“Human working”)

    def eat(self):
        print(“Human eating”)

# A robot only implements Workable, not Eatable
class RobotWorker(Workable):
    def work(self):
        print(“Robot working”)

# Client code is now tailored to each type of worker
def perform_work(worker: Workable):
    worker.work()

def take_lunch_break(worker: Eatable):
    worker.eat()

# Test with HumanWorker and RobotWorker
human = HumanWorker()
robot = RobotWorker()

perform_work(human)
take_lunch_break(human)  # Human can eat
perform_work(robot)
# Robot cannot take a lunch break since it’s not an Eatable

from abc import ABC, abstractmethod

# Separate interfaces

class Workable(ABC):

@abstractmethod

def work(self):

pass

class Eatable(ABC):

@abstractmethod

def eat(self):

pass

# A human worker implements both Workable and Eatable

class HumanWorker(Workable, Eatable):

def work(self):

print(“Human working”)

def eat(self):

print(“Human eating”)

# A robot only implements Workable, not Eatable

class RobotWorker(Workable):

def work(self):

print(“Robot working”)

# Client code is now tailored to each type of worker

def perform_work(worker: Workable):

worker.work()

def take_lunch_break(worker: Eatable):

worker.eat()

# Test with HumanWorker and RobotWorker

human = HumanWorker()

robot = RobotWorker()

perform_work(human)

take_lunch_break(human) # Human can eat

perform_work(robot)

# Robot cannot take a lunch break since it’s not an Eatable

Benefits of ISP in this Example

Separation of Concerns: By segregating the Workable and Eatable interfaces, we ensure that each client (e.g., RobotWorker or HumanWorker) only depends on the methods it truly requires.
Better Maintainability: If in the future we want to change how eating works for humans, we can modify the Eatable interface and the related implementations without affecting robots.
Avoid Unused Code: The RobotWorker class no longer has to implement a meaningless eat method, resulting in cleaner, more intuitive code.

Conclusion

The Interface Segregation Principle is a powerful tool in object-oriented design that helps reduce dependencies on unnecessary methods, making your code more modular and maintainable. By splitting large interfaces into smaller, client-specific ones, ISP ensures that each class or module only has to deal with the functionality it truly needs, preventing bloated and unwieldy implementations.

By applying ISP, we create more robust, flexible, and scalable systems where changes to one part of the system are less likely to break other parts.