Interface Segregation Principle in LLD - System Design Guide

Problem Statement

When a single interface forces clients to depend on methods they do not use, it leads to bloated implementations and fragile code. This causes unnecessary coupling and makes the system harder to maintain and extend.

Solution

This principle solves the problem by splitting large interfaces into smaller, more specific ones. Clients then only implement the interfaces relevant to them, reducing unnecessary dependencies and improving code clarity and flexibility.

Architecture

Client A

→Interface A

↓

Client B

→Interface B

This diagram shows clients depending only on the interfaces they need, each implemented separately, avoiding unnecessary method dependencies.

Trade-offs

✓ Pros

→

Reduces unnecessary dependencies between clients and interfaces.

→

Improves code maintainability by isolating changes to specific interfaces.

→

Enhances flexibility by allowing clients to implement only relevant methods.

→

Facilitates easier testing and mocking of smaller interfaces.

✗ Cons

→

Increases the number of interfaces, which can add complexity to the codebase.

→

Requires careful design to avoid interface explosion with too many tiny interfaces.

→

May require more upfront design effort to identify appropriate interface boundaries.

Use when interfaces have multiple unrelated methods and clients only need subsets of them, especially in medium to large codebases with multiple client types.

Avoid when interfaces are naturally small and cohesive, or in very simple systems where added interface splitting adds unnecessary complexity.

Real World Examples

Amazon

Amazon uses interface segregation in their payment processing system to separate payment authorization, capture, and refund operations, allowing different clients to implement only needed parts.

Netflix

Netflix applies interface segregation in their streaming service APIs to separate playback controls from user preferences, so clients only depend on relevant features.

Uber

Uber uses interface segregation in their driver and rider apps to separate location tracking interfaces from payment interfaces, reducing unnecessary dependencies.

Code Example

The before code forces OldPrinter to implement scan and fax methods it does not support, violating the principle. The after code splits the large interface into smaller ones, so SimplePrinter only implements printing, avoiding unused methods.

LLD

### Before applying Interface Segregation Principle (violating)

class MultiFunctionDevice:
    def print(self, document):
        pass
    def scan(self, document):
        pass
    def fax(self, document):
        pass

class OldPrinter(MultiFunctionDevice):
    def print(self, document):
        print(f"Printing {document}")
    def scan(self, document):
        raise NotImplementedError("Scan not supported")
    def fax(self, document):
        raise NotImplementedError("Fax not supported")


### After applying Interface Segregation Principle (applying)

from abc import ABC, abstractmethod

class Printer(ABC):
    @abstractmethod
    def print(self, document):
        pass

class Scanner(ABC):
    @abstractmethod
    def scan(self, document):
        pass

class Fax(ABC):
    @abstractmethod
    def fax(self, document):
        pass

class SimplePrinter(Printer):
    def print(self, document):
        print(f"Printing {document}")

class MultiFunctionMachine(Printer, Scanner, Fax):
    def print(self, document):
        print(f"Printing {document}")
    def scan(self, document):
        print(f"Scanning {document}")
    def fax(self, document):
        print(f"Faxing {document}")

Alternatives

Single Interface

Uses one large interface with all methods combined, forcing clients to implement unused methods.

Use when: Only when the system is very simple and clients always need all methods.

Abstract Base Class

Uses a base class with default implementations instead of multiple small interfaces.

Use when: When inheritance is preferred and default behavior can be shared.

Summary

Interface Segregation Principle prevents clients from depending on methods they do not use by splitting large interfaces into smaller, specific ones.

This reduces unnecessary coupling, improves maintainability, and increases flexibility in code design.

It is best applied in medium to large systems where clients have diverse needs, but avoided in simple cases to prevent complexity.