Interface Segregation Principle

and how to interpret it

I wish all of my interfaces were segregated as good as this fish at Catania fish market

It’s a fourth post on SOLID principles. Check out the previous one, Liskov Substitution Principle, in case you missed it.

Definition

According to Robert Martin,

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

Besides, Wikipedia has a concise description of a practice leading you to a situation when your code is complied with ISP:

ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces.

I believe there is a deep foundation behind this principle, much like Kent Beck’s XP values are a foundation for his XP principles.

Correct abstraction is the key to Interface Segregation Principle

Wiki’s definition states nothing more than that your abstractions should be correct, thus the classes implementing them end up being small, and cohesive, and solid.

Finding correct abstractions is more of an art. Definitely, you should explore your domain, probably build some semantic nets, come up with a set of user stories, draw interaction diagrams — and all of that doesn’t necessarily lead you to correct abstractions. Wrong abstractions are worse than no abstractions at all, so don’t forget about the Rule of Three.

When you think you’re done with some of your abstractions, represent them as interfaces. The techniques mentioned above reinforce them to be a Role Interfaces. With this approach, concrete classes implement only as much as those abstractions require them to. So we end up with satisfying the Interface Segregation Principle even without knowing that it exists.

Violation of Interface Segregation Principle

When a client depends on methods it doesn’t use, it means that your abstractions are wrong. Martin Fowler’s example of Role Interface (which is a natural consequence of applying ISP) just exposes wrong initial object decomposition. And it doesn’t take a standalone principle to claim that. The code is plainly not cohesive. So don’t ponder on whether your code violates Interface Segregation Principle, think about whether your abstractions are correct.

Code example?

No, it’s not much sense in it. Giving some random piece of code won’t tell much about domain abstractions and contracts they follow. Anyways, there are plenty of examples on the internet where some class has to implement some fat interface’s behavior that it’s not supposed to.

Final words

This principle comes naturally when you start decomposing your problem space with identifying major roles that take part in your domain. And it’s never a mechanical action. No principle can automatically lead you to the correct object model.

So ISP is a poor guidance when designing software, but an excellent indicator of whether it’s healthy or not. Don’t think about ISP when designing your software. Think about whether your abstractions are reusable and composable, and whether your objects are encapsulated and cohesive.