Interface Segregation Principle: Your only way to be a super competent developer

During development, the code tends to be long. At some point, the codebase becomes so bloated that you can’t handle it. Nevertheless, senior developers make things work somehow. How do they do that? “All enterprise level developers actively use interfaces”. So today, I am going to explain Interface Segregation Principle in one of SOL’I’D PRINCIPLE. If you didn’t know this, you should know that you are falling behind.

What is Interface Segregation Interface?

No client should be forced to depend on methods it does not use

Interface Segregation Principe is also called ISP for abbreviation. When you write code, it’s pretty easy to violate ISP, because your software evolves and you have to add more features. The aim of ISP is to minimize the side effects by splitting the software into independent parts. The point is “YOU SHOULD ONLY DEFINE METHODS THAT ARE GOIND TO BE USED”.

Bad Practices

interface IMultiFunction {
public void print();
public void getPrintSpoolDetails();
public void scan();
public void scanPhoto();
public void fax();
public void internetFax();
}

What do you think? Do you think the code example above has nothing wrong?

Firstly, you need to ask yourself if the methods defined inside IMultiFunction is cohesive. Obviously, print() and getPrintSpoolDetails() are cohesive. But how about print() and scan() ? Does all printing machines support for these features?

I’m going to show you another example.

class CanonPrinter implements IMultiFunction {

@Override
public void print() {}

@Override
public void getPrintSpoolDetails() {}

/* This machine can't scan */
@Override
public void scan() {}

/* This machine can't scan photo */
@Override
public void scanPhoto() {}

/* This machine can't fax */
@Override
public void fax() {}

/* This machine can't fax on internet */
@Override
public void internetFax() {}

}

CanonPrinter can’t fax. But it still needs to implement fax().

In software development, Unimplemented methods are almost always indicative of a poor design.”

So, what should you do?

Good Practices

ISP starts from splitting big interfaces into smaller interfaces.

Let’s refactor !

interface IPrint {
public void print();
public void getPrintSpoolDetails();
}

interface IScan {
public void scan();
public void scanPhoto();
}

interface IFax {
public void fax();
public void internetFax();
}

This is a much better approach. Not only did you split big interfaces into smaller interfaces, it has also nicely defined functionalities which also satisfy Single Responsibility Principle.

class HPPrintNScanner implements IPrint, IScan {

@Override
public void scan() {
// TODO Auto-generated method stub

}

@Override
public void scanPhoto() {
// TODO Auto-generated method stub

}

@Override
public void print() {
// TODO Auto-generated method stub

}

@Override
public void getPrintSpoolDetails() {
// TODO Auto-generated method stub

}

}

As you can see, HPPrintNScanner implemented only necessary methods.

Techniques to identify violations

  1. Find if your Interfaces have methods with low cohesion
  2. Check Empty Method Implementations

Conclusion

You’ve learned some great techniques that will increase the quality of your code. This is one step closer to making a scalable application. Go practice practice practice!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
KD Knowledge Diet

Software Engineer, Mobile Developer living in Seoul. I hate people using difficult words. Why not using simple words? Keep It Simple Stupid!