This is the ‘eye’ of SOLID software design principles.
Definition:
Clients should not be forced to depend on methods that they do not use.
Alternate Definition (s):
The dependency of one class to another one should depend on the smallest possible interface
The idea
Consider two components- which interact with each other. The interaction between the two is defined by the API calls that one makes onto another. The component which makes calls to the other serves as the client.
The methods that the client can call upon the component serves as the contract between the two.This contract should be kept thin. It should have all that the client needs- and nothing more. Keep in mind- what the component exposes to the client is not limited only to the interface explicitly implemented by the component – but also included all the behavior inherited by that component from classes\interfaces up the hierarchy
Example of violation
Lets say I have domain classes- PurchaseOrder, Appointment , Invoice etc. All domain classes extend the same base class- DomainClass which contains common behavior.
All my domain class can be published to external entities. So we have a method publish (). Now if we want to keep this behavior internal to these objects- i.e. only the domain classes will decide when its the time to be published- this method should be declared as protected. If we declare this method as public- all clients would have access to this method- if that was not the intention- we have violated the Interface Segregation Principle.
Another common violation is when we have an interface say Animal with methods – run (); swim (); fly ()
And Classes – Fish , Horse etc.- all implementing the Animal interface
Now since flying is a behavior not exhibited by all animals- we provide a dummy implementation and throw and Error “NotSupported”. This is a voilation of the principle. You have exposed the method fly () to all clients of the class Horse when they didn’t even need it.
In fact – in a twisted sort of way – the Object class,the Parent of all classes in Java, is a violation of Interface Segregation Principle. All methods in Object are exposed to all clients.
The Benefits
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.
Credits
Read more about this from the Master , Robert Martin himself.
Recent Comments