Is Interface segregation principle only a substitue for Single responsibility principle?

Question

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

Answer 1

I think that if my class fulfill SRP there is no need to extract more than one interface.

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 a Gearbox class. This means that if you change the mechanism behind gear changes, the parent Car 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 the Car itself downwards, you'll find that the detail increases in each class — e.g. while the Car class may have a changeGear() method to allow the user to select a gear to engage, the Gearbox 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 as private or protected).

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 the Car class delegates its sub-components to different classes, but all of our public methods will still be called through the Car 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.