Interface Segregation Principle
We will be discussing the Interface Segregation Principle also known as ISP, as one of the SOLID principles of object-oriented programming and how to implement it when designing our software.
This principle says that Clients should not be forced to depend upon interfaces that they do not use.
This means that an interface that creates a small will do only a unique job, larger interfaces should be split into smaller ones.
Example
Let us define an interface to violates ISP that contains code.
Create ICompanyDepartment Interface that contains only the company departments.
interface ICompanyDepartment {
public void AdminDepartment();
public void ITDepartment();
public void FinanaceDepartment();
public void HRDepartment();
}
Let’s start by implementing the ICompanyDepartment for Company as NirmalCompany.cs
class NirmalCompany: ICompanyDepartment {
public void AdminDepartment() {
throw new NotImplementedException();
}
public void FinanaceDepartment() {
throw new NotImplementedException();
}
public void HRDepartment() {
throw new NotImplementedException();
}
public void ITDepartment() {
throw new NotImplementedException();
}
}
Now suppose one more SheebaCompany comes that only works on manufacturing and they don’t have IT department then the above implementation has one problem,
If you add ManufacuringDepartment on IcompanyDepartment interface then we have to implement the signature on both classes
- NirmalCompany
- SheebaCompany.
This part is a violation of ISP principle.
When you implement the ICompanyDepartment interface you must be adding all signatures but SheebaCompany doesn’t want ITDepartment.
Above implementation is clear violation of Interface Segregation Principle
Again, modify the code as per the ISP Principle.
Initialize the three interfaces
- ICompanyDepartment
- INirmalCompanyUniqueFeature
- ISheebaCompanyUniqueFeature
interface ICompanyDepartment {
public void AdminDepartment();
public void FinanaceDepartment();
public void HRDepartment();
}
interface INirmalCompanyUniqueFeature {
public void ITDepartment();
}
interface ISheebaCompanyUniqueFeature {
public void ManufacuringDepartment();
}
class NirmalCompany: ICompanyDepartment, INIrmalCompanyUniqueFeature {
public void AdminDepartment() {
throw new NotImplementedException();
}
public void FinanaceDepartment() {
throw new NotImplementedException();
}
public void HRDepartment() {
throw new NotImplementedException();
}
public void ITDepartment() {
throw new NotImplementedException();
}
}
class SheebaCompany: ICompanyDepartment, ISheebaCompanyUniqueFeature {
public void AdminDepartment() {
throw new NotImplementedException();
}
public void FinanaceDepartment() {
throw new NotImplementedException();
}
public void HRDepartment() {
throw new NotImplementedException();
}
public void ManufacuringDepartment() {
throw new NotImplementedException();
}
}
Conclusion
Even though the name of the principle is self-explanatory, we can see how easy it is to implement correctly. Make sure to distinguish the responsibility of every class.