![]() In one way ISP is just like following clean code: create small interfaces/classes. In my opinion, especially the relationship with SRP makes it a principle worth to follow. ISP is quite powerful SOLID principle because it helps to follow even two other SOLID principles: SRP and LSP. Similar to the Single Responsibility Principle, the goal of the Interface Segregation Principle is to reduce the side effects and frequency of required changes by splitting the software into multiple, independent parts. ISP reduces modifying multiple files like SRP. Doesn’t this sound familiar? Yes, it is the single responsibility principle (SRP) that I wrote a blog post earlier in this series. That reduces changes to those interfaces, and probably also to classes that implement it because there is now only one reason to change them. If we define thin interfaces as ISP suggests, each interface will have only one role. Helps Also With Single Responsibility Principle And as we saw in the previous LSP blog post it will violate also LSP. If we violate ISP and have some method in the interface that all clients won’t use, then we are forced to for example just throw NotSupportedException in those subclasses. And if we always implement all methods of interface it will help also to follow LSP. Because if we follow ISP, then we won’t have any classes that can’t implement some method of the interface. If we follow ISP it also helps us to follow the Liskov substitution principle (LSP). Martin) Helps With Liskov Substitution Principle Make fine grained interfaces that are client specific. In this way, there won’t be methods in the interface that the client doesn’t use. How to Create ISP Friendly Interfaces? The answer to this question is little tricky: don’t create them, let clients who will use the interface, define it. Role interface name comes from because the interface has a specific role which could be just that one method. And small interfaces with just few methods he calls role interfaces. In his Encapsulation and SOLID Pluralsight course, Mark Seemann called these fat interfaces header interfaces because they look like C++ header files. Then clients of interfaces are free to choose what interface(s) they want to use and not forced to implement methods they don’t even need (like Turbo method for a regular car). Practically ISP means that use small interfaces with even only one method rather than one fat interface with many methods. Many client specific interfaces are better than one general interface. In this example we followed a rule for ISP: But still, they can implement it via ISportsCar if they want. This doesn’t violate ISP because no car isn’t forced to implement Turbo method. Now our slower cars don’t have to implement the Turbo method but sports cars, like Ferrari and Porche, can implement ISportsCar interface and Turbo method. The easiest way is to extract Turbo method to its own ISportsCar interface: Let’s try to fix the ICar interface to apply ISP. Slow cars are now forced to implement Turbo method that they do not use. Because we have two classes with turbo, we decide to add new Turbo method to the ICar interface:īut that forces us to implement Turbo method to slower cars also. Then comes a day when we implement Ferrari and Porche classes with a turbo. Some time passes and we make some classes that implement ICar interface. Suppose we have an ICar interface with few methods: Example of Violating ISP When Adding New Method I will explain this first with an example of violating it. ![]() This needs some explanation like other SOLID principles has had in this series. That is the definition of the interface segregation principle (ISP). Clients should not be forced to depend upon interfaces that they do not use. (Robert C.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |