Interface Segregation Principle and How to Interpret 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 provides a concise description of code compiled 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 that are a foundation for his XP principles.

Correct Abstraction

Correct abstraction is key to the 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, cohesive, and solid.

Finding correct abstractions is more of an art. You should explore your domain, 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 Role Interfaces. With this approach, concrete classes implement only as much as those abstractions require them to. So, we end up satisfying the Interface Segregation Principle without knowing that it exists.

Violation of the Interface Segregation Principle

When a client depends on methods that it doesn’t use, it means that your abstractions are wrong. Martin Fowler’s example of the Role Interface (which is a natural consequence of applying ISP) exposes a 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 the Interface Segregation Principle; think about whether your abstractions are correct.

Code Example?

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

Final Thoughts

This principle comes naturally when you start decomposing your problem space by 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.