In-person payments deal with the walk-in customers as well as telephone customers. It also contains methods for handling online payments (for online customers) and in-person payments. Let’s assume that there is a Restaurant interface which contains methods for accepting orders from online customers, telephone customers and walk-in customers. As fewer classes share these interfaces, the number of changes that are required in response to an interface modification is lowered, which increases robustness.īasically, the lesson here is “Don’t depend on things you don’t need”. Smaller interfaces are easier to implement, improving flexibility and the possibility to reuse. When you apply ISP, classes and their dependencies communicate using tightly-focused interfaces, minimizing dependencies on unused members and reducing coupling accordingly.
In short, it would be bad for you to force the client to depend on a certain thing, which they don’t need. So basically, the interface segregation principles as you prefer the interfaces, which are small but client specific instead of monolithic and bigger interface. By doing so, we can ensure that implementing classes only needs to be concerned about the methods that are of interest to them.Ī client, no matter what, should never be forced to implement an interface that it does not use or the client should never be forced to depend on any method, which is not used by them. Larger interfaces should be split into smaller ones. When we have non-cohesive interfaces, the ISP guides us to create multiple, smaller, cohesive interfaces. The Interface Segregation principle says that “Clients should not be forced to depend upon interfaces that they do not use.”
#Violation of single responsibility principle code#
If you review your project code thoroughly, you will find that this principle is the most violated just because we don’t focus on the good design while coding.
0 kommentar(er)
