Understanding the Interface Segregation Principle (ISP) with C#

Introduction

C# is an object-oriented programming language. These days whenever you talk about object-oriented programming you hear the acronym, SOLID. These are five design principles introduced by Michael Feathers to make our object-oriented applications easy to understand, maintain, and expand as future requirements change. Today, we will look at the fourth principle with an example. I covered the first three principles in my previous articles.

The SOLID principles

There are five principles to follow to ensure our application meets the SOLID requirements. These are shown below:

Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

The Interface Segregation Principle (ISP)

The Interface Segregation Principle (ISP) states that a class must not have to implement any interface element that is not required by the particular class. This will ensure the class and ultimately the whole application is very robust and easy to maintain and expand if required. Let us look at this with an example:

Let's create a new .NET Core 3.1 console application in Visual Studio 2019 Community Edition, as shown below:

Inside this project, I have created a new class file “InterfaceSegregationPrinciple”. In this file, I created the following interfaces and classes.

// Not following the Interface Segregation Principle
public interface IWorker
{
string ID { get; set; }
string Name { get; set; }
string Email { get; set; }
float MonthlySalary { get; set; }
float OtherBenefits { get; set; }
float HourlyRate { get; set; }
float HoursInMonth { get; set; }
float CalculateNetSalary();
float CalaculateWorkedSalary();
}
public class FullTimeEmployee : IWorker
{
public string ID { get; set; }
public string Name { get; set; }
public string Email { get; set; }
public float MonthlySalary { get; set; }
public float OtherBenefits { get; set; }
public float HourlyRate { get; set; }
public float HoursInMonth { get; set; }
public float CalculateNetSalary() => MonthlySalary + OtherBenefits;
public float CalaculateWorkedSalary() => throw new NotImplementedException();
}
public class ContractEmployee : IWorker
{
public string ID { get; set; }
public string Name { get; set; }
public string Email { get; set; }
public float MonthlySalary { get; set; }
public float OtherBenefits { get; set; }
public float HourlyRate { get; set; }
public float HoursInMonth { get; set; }
public float CalculateNetSalary() => throw new NotImplementedException();
public float CalaculateWorkedSalary() => HourlyRate * HoursInMonth;
}

This class does not follow the “Interface Segregation Principle” as the FullTimeEmployee class does not need to implement the CalculateWorkedSalary function and the ContractEmployee class does not need to implement the CalculateNetSalary function. We can fix this issue as shown below:

// Following the Interface Segregation Principle
public interface IBaseWorker
{
string ID { get; set; }
string Name { get; set; }
string Email { get; set; }
}
public interface IFullTimeWorkerSalary : IBaseWorker
{
float MonthlySalary { get; set; }
float OtherBenefits { get; set; }
float CalculateNetSalary();
}
public interface IContractWorkerSalary : IBaseWorker
{
float HourlyRate { get; set; }
float HoursInMonth { get; set; }
float CalaculateWorkedSalary();
}
public class FullTimeEmployeeFixed : IFullTimeWorkerSalary
{
public string ID { get; set; }
public string Name { get; set; }
public string Email { get; set; }
public float MonthlySalary { get; set; }
public float OtherBenefits { get; set; }
public float CalculateNetSalary() => MonthlySalary + OtherBenefits;
}
public class ContractEmployeeFixed : IContractWorkerSalary
{
public string ID { get; set; }
public string Name { get; set; }
public string Email { get; set; }
public float HourlyRate { get; set; }
public float HoursInMonth { get; set; }
public float CalaculateWorkedSalary() => HourlyRate * HoursInMonth;
}

In the above code, we see that we have created a base interface which has the common properties of all employees. Then, we created two more interfaces which implement the base interface and these interfaces are for the full time and contract employee, respectively. They only contain properties and methods for the particular type of employee. Finally, in our classes for the full time and contract employee, we only implement the required interface (full time or contract). No additional method or property is required.

Summary

In this article, we have looked at implementing the Interface Segregation Principle (ISP) in a practical example. I would recommend you look through your existing classes and identify places where you have violated this principle and then think of ways to fix it. This will help to get you thinking in terms of applying this principle and help you to apply it to your code in the future as well. In my next article, we will look at the last principle, the Dependency Inversion Principle.