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 principles. Check out the previous one, , in case you missed it. SOLID Liskov Substitution Principle Definition According to Robert Martin, The ( ) states that no client should be forced to depend on methods it does not use. interface-segregation principle ISP Besides, has a concise description of a practice leading you to a situation when your code is complied with ISP: Wikipedia 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 values are a foundation for his XP principles. Kent Beck’s XP 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 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 . correct abstractions 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 . 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. Role Interfaces 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 (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. Role Interface 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 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. decomposing your problem space 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.
![Clean Code: Interface Segregation, Dependency Inversion, SOLID Principles in TS [Part 5]](https://hackernoon.imgix.net/images/erom0wkF6nZC8UOvFBqlbSeNR4J2-n4831b1.jpeg?auto=format&fit=max&w=3840)
