What is the reasoning behind the Interface Segregation Principle?

The interface segregation is the “I” on the SOLID principle, before digging too deep with the first, let’s explain what’s does the latter mean.

SOLID can be considered a set of best practices and recommendations made by experts (meaning they have been proved before) in order to provide a reliable foundation in how we design applications. These practices strive to make easier to maintain, extend, adapt and scale our applications.

Why should I care about SOLID programming?

First of all, you have to realize you are not going to be forever where you are. If we use standards and well known architectures, we can be sure that our code will be easy to maintain by other developers that come after us, and I’m sure you wouldn’t want to deal with the task of fixing a code that didn’t applied any known methodology as it would be very hard to understand it.

The interface segregation principle.

Know that we know what the SOLID principles are we can get into more detail about the Interface Segregation principle, but what exactly does the interface segregation says?

“Clients should not be forced to implement unnecessary methods which they will not use”

This means that sometimes we tend to make interfaces with a lot of methods, which can be good to an extent, however this can easily abused, and we can end up with classes that implement empty or useless methods which of course adds extra code and burden to our apps. Imagine you are declaring a lot of methods in single interface, if you like visual aids a class that is implementing an interface but that is really needing a couple of methods of it would look like this:

In the other hand, if you properly apply the interface segregation and split your interface in smaller subsets you can me sure to implement those that are only needed:

See! Is way better! Enforcing this principle will allow you to have low coupling which aids to a better maintainability and high resistance to changes. So you can really leverage the usage of interfaces and implementing the methods when you really should. Now let’s review a less abstract example, say you declared an interface called Reportable

public interface Reportable {

        void printPDF();
        void printWord();
        void printExcel();
        void printPPT();
        void printHTML();


}

And you have a client that will only to export some data in Excel format, you can implement the interface, but would you only have to implement the excel method? The answer is no, you will have to code the implementation for all the methods even if you are not going to use them, this can cause a lot of junk code hence making the code hard to maintain..

Remember keep it simple and don’t repeat yourself and you will find that you are already using this principle without knowing.

ISP states that:

Clients should not be forced to depend on methods that they do not use.

ISP relates to important characteristics - cohesion and coupling.
Ideally your components must be highly tailored. It improves code robustness and maintainability.

Enforcing ISP gives you following bonuses:

• High cohesion - better understandability, robustness
• Low coupling - better maintainability, high resistance to changes

If you want to learn more about software design principles, get a copy of Agile Software Development, Principles, Patterns, and Practices book.