Is interface segregation principle only a substitue for single responsibility principle ?
I think that if my class fulfill SRP there is no need to extract more than one interface.
So ISP looks like solution in case we have to break SRP for some reason.
Am I right ?
No. Take the example of a class whose responsibility is persisting data on e.g. the harddrive. Splitting the class into a read- and a write part would not make practical sense. But some clients should only use the class to read data, some clients only to write data, and some to do both. Applying ISP here with three different interfaces would be a nice solution.
Single Responsibility Principle is that a class (or a method) shouldn't have more than one reason to change (i.e. each responsible for just one feature). To honour this, you'll find yourself creating new classes as your system develops.
E.g. if you start with a
Car
class & find that you need functionality to change the gears, you'll extract this into aGearbox
class. This means that if you change the mechanism behind gear changes, the parentCar
class doesn't need to change. If you add power-steering to your car, you'll again extract this into it's own class. The radio would be another class.This cascade of abstraction will happen throughout your
Car
class. As you move from theCar
itself downwards, you'll find that the detail increases in each class — e.g. while theCar
class may have achangeGear()
method to allow the user to select a gear to engage, theGearbox
class will look after the nitty-gritty of making this happen (e.g. depress the clutch, disengage the current gear, select the new gear, etc.)With an OO design however, we don't want to expose the details of our
Gearbox
to the end user — we want them to interact with our system at a high level of abstraction, without needing to know how the internals work. We also want to ring-fence these internals, so that we can change them in the future without needing the users to refactor their code (which is why we'd flag them asprivate
orprotected
).Because of this, we let users interact with our car only through the
Car
class itself. This is where the Interface Segregation Principle comes in. SRP ensures that theCar
class delegates its sub-components to different classes, but all of ourpublic
methods will still be called through theCar
class itself. ISP ensures that rather than lumping all these together in one interface, we instead create logical distinctions & expose multiple interfaces for related functionality.No.
A class can implement multiple interfaces but it should implement the methods only applicable to it.
Assume that you have 10+ different capabilities like
Climb, Think, Learn, Apply
. ClassDog
can have 2 capabilities and classCat
can have 2 capabilities and classMan
can have 6 capabilities. It makes sense to implement only applicable capabilities in respective classes.Have a look at this code.
output:
In above example, interface segregation recommends to define 10 capabilities in 10 interfaces in stead of declaring all of them in fat interface. But it does not mean that you need different classes to meet single responsibility criteria.
Have a look at implementation of
Dog, Cat and Man
classes in same example.