Interface Segregation Principle: SOLID design
How to say good bye to Interface Pollution
Welcome to the five-part series of blog posts about SOLID Principles. This is fourth part where we will be having deep dive into I part (Interface Segregation Principle) of SOLID principles. If you have not gone through the previous posts please have a look:
- Single Responsibility Principle
- Open / close principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
4. Interface Segregation Principle:
The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.
The goal of the Interface Segregation Principle is similar to Single Responsibility principle and that is to reduce the side effects and frequency of required changes by splitting the software into multiple, independent parts.
Use Case:
Suppose we got a requirement to design a software for a company. Company has two types of workers, contract and permanent workers. Both types of workers works and they need a daily launch break to eat. We can design the classes as:
interface IWorker {
public void work();
public void eat();
}
class ContractWorker implements IWorker{
public void work() {
// ....working
}
public void eat() {
// ...... eating in launch break
}
}
class PermanentWorker implements IWorker{
public void work() {
//.... working much more
}
public void eat() {
//.... eating in launch break
}
}This will work well. But suppose a new requirement comes and company introduces some Robots that can do the work efficiently, but they don’t eat.
If we keep the present design, the new Robot class is forced to implement the eat method. This will violate Interface Segregation Principle. Such an interface is named fat interface or polluted interface. Having an interface pollution is not a good solution and might induce inappropriate behaviour in the system.
class RobotWorker implements IWorker{
public void work() {
//.... working much more
}
public void eat() {
// either throw exception or do No operation here
}
}To incorporate the Interface Segregation Principle, we can split IWorker interface into 2 different interfaces. So our design will looks like:
interface IWorkable {
public void work();
}
interface IFeedable{
public void eat();
}
class ContractWorker implements IWorkable, IFeedable{
public void work() {
// ....working
}
public void eat() {
//.... eating in launch break
}
}
class RobotWorker implements IWorkable{
public void work() {
// ....working
}
}
class PermanentWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}
public void eat() {
//.... eating in launch break
}
}Caution:
If we are going to apply it for more than what is necessary, it will result a code containing a lot of interfaces with single methods, so application should be based on experience and common sense in identifying the areas where extension of code are more likely to happens in the future.
I hope this explanation has given some insights on Interface Segregation principle of SOLID principles. Also it will allow you to adopt an approach that works during your software design.
I’m looking forward to writing on rest principles of SOLID. 👏 clap 👏 if you learnt at-least one thing & share if you feel the content deserves. Give Feedback, Comment or start a discussion. Feel free to correct mistakes. Cheers!