What Does ISP Try To Solve?

ISP suggests that rather than creating large, all-encompassing interfaces with many methods (often referred to as "fat interfaces"), you should create smaller, more focused interfaces that only contain the methods relevant to the specific classes that implement them.

Without ISP, you could end up with an interface that has methods for a wide range of unrelated tasks, here’s some problems you might come across:

Unnecessary code: Classes end up with methods they don't need, which can confuse developers and introduce bugs.
Increased maintenance complexity: Changes to one part of a large interface can ripple through your codebase, forcing modifications to classes that have no interest in the functionality.
Poor cohesion: If an interface is trying to do too much, it can lead to classes being loosely coupled and harder to maintain in the long run.

The goal is to avoid situations where a class has to implement methods that are not needed for its functionality. This makes your code more modular, flexible, and easier to maintain because each interface is highly focused on a specific concern or behaviour.

The Definition

So, what exactly is the Interface Segregation Principle?

"Clients should not be forced to depend on interfaces they do not use."

To better understand this, let’s break it down:

"Clients": These are the classes, components, or objects that will implement or use interfaces.
"Depend on interfaces": This refers to the idea that classes rely on the methods or behaviors defined in an interface. When a class implements an interface, it must define the methods that the interface declares.
"Do not use": This part is crucial because it highlights that a class should not be forced to implement methods that it doesn’t need.

Real-World Example

Imagine a MultiFunctionPrinter interface that combines both printing and scanning functionality:

interface MultiFunctionPrinter {
    public function printDocument(string $document): void;
    public function scanDocument(string $document): void;
}

Now, let’s create two classes: one for a Printer and one for a Scanner:

class Printer implements MultiFunctionPrinter {
    public function printDocument(string $document): void {
        echo "Printing: $document";
    }

    public function scanDocument(string $document: void) {
        // Does nothing, since this class only prints
    }
}

class Scanner implements MultiFunctionPrinter {
    public function printDocument(string $document): void {
        // Does nothing, since this class only scans
    }

    public function scanDocument(string $document): void {
        echo "Scanning: $document";
    }
}

Here, both Printer and Scanner are forced to implement methods that are irrelevant to them. For instance, Printer doesn't need scanDocument, and Scanner doesn't need printDocument. This violates ISP because each class is forced to depend on methods that don't apply to its purpose.

To comply with ISP, we should separate the MultiFunctionPrinter into two smaller, more focused interfaces:

interface Printer {
    public function printDocument(string $document): void;
}

interface Scanner {
    public function scanDocument(string $document): void;
}

Now we can implement these interfaces without forcing unnecessary methods:

class PrinterClass implements Printer {
    public function printDocument(string $document): void {
        echo "Printing: $document";
    }
}

class ScannerClass implements Scanner {
    public function scanDocument(string $document): void {
        echo "Scanning: $document";
    }
}

This way, the Printer class only implements the printing functionality, and the Scanner class only implements scanning functionality, each class is adhering to its specific responsibility.

Conclusion

The Interface Segregation Principle (ISP) encourages developers to create smaller, more specific interfaces that only contain the methods relevant to the classes that implement them.

By adhering to this principle, you can avoid forcing classes to implement unnecessary methods, improving code clarity, maintainability, and flexibility.

In the end, the goal is to create a system where classes depend only on what they truly need, making the codebase cleaner and more modular.

The Grumpy Dev is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.