Also known as
Interface Segregation Principle: Clients should not be forced to depend upon interfaces that they don’t use.
Alternate Definition: The dependency of one class to another one should depend on the smallest possible interface
How do I design a interface?
As we define our interfaces, it becomes important that we clearly understand the role the interface plays within the context of our application, when defining the operation on an interface, we should do so in a manner that doesn’t accommodate multiple roles. Therefore, an interface should be responsible for allowing an object to assume a SINGLE ROLE, assuming the class of which that object is an instance implements that interface.
Like every principle, Interface Segregation Principle requires additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than necessary, it will result in a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where extension of code are more likely to happen in the future.
This principle is important because it encourages two very important ingredients of a good software design:
- High cohesion - Keep all related methods together
- Low coupling - Keep dependence of one another to the bare minimum
Changes to fat interfaces tend to cause a ripple affect to classes who shouldn’t have been affected in the first place.
Java Collection API is a good example on interface segregation. Classes can depend on Collection, List, Set, SortedSet etc. depending on what type of collection they want to use. If everything was bundled in a single interface then any change to that interface would mean a ripple effect in all collection classes. All types of Lists maintain a high cohesion. Client code is dependent on minimal interface required.
- The LCOM4 metric in Sonar can help reveal violations of this principle in an existing code base.