This is the Demystify SOLID article series. In this series we will be talking about SOLID principals of software architecture, if are very interesteded in learning good practices and design then you are in the right place.
In our previous article we have discussed the “Single responsibility principal”. If you are new to this series then you can read it here.
Demystify SOLID: "S" For Single Responsibility Principal
Demystify SOLOD: "S" for Single responsibility principal
As per the title, we will understand the concept of “Open close principal in this article”. It's another good principal of application development. The open close principal suggests that “One class (or software component) will be always open for extension and closed for modification”. Let's discuss that a little.
public class employeeProcess
{
public string employeeName { get; set; }
public void PrintEmployeeType(int type)
{
if (type == 1)
Console.WriteLine("Permanent Employee");
else if (type == 2)
Console.WriteLine("Temporary Employee");
}
}
We have designed the “employeeProcess” class that will happily print an employee type using the “PrintEmployeetype()” function. The logic is pretty simple, we are checking the input type of the function. If the type is 1 then it will print Permanent Employee and if the type is 2 then it will print Temporary employee.
Fine, and simple. But here is one limitation in this definition. If the organization then adds one more type of employee in the organization like “contractual employee” then they need to modify the exhisting employeeProcess class. Is that inconsistent with the “Open close principal”? Because we know that the component will be opened for extension but closed for modification but we are trying to modify the existing class. So, what is the solution? It's simple, when it is ndecessary to add new functionality to an existing class, just extend the class rather than modify it. Here is the modified implementation.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Data.SqlClient;
using System.Data;
using System.Collections.ObjectModel;
namespace FuncTest
{
public class employee
{
public string employeeName { get; set; }
public virtual void PrintEmployeeType(int type){}
}
public class PermanentEmployee : employee
{
public override void PrintEmployeeType(int type)
{
Console.WriteLine(employeeName);
Console.WriteLine("I am Permanent Employee");
}
}
public class ContuctBasedEmployee : PermanentEmployee
{
public override void PrintEmployeeType(int type)
{
Console.WriteLine(employeeName);
Console.WriteLine("I am Contuct based Employee");
}
}
class Program
{
static void Main(string[] args)
{
employee e = new PermanentEmployee();
e.employeeName = "Sourav";
e.PrintEmployeeType(1);
Console.ReadLine();
}
}
}
So, what we have done to overcome the limitation? We have just created a new class that will take the responsibility of a new type of employee and in this way we are maintaining the open close principal of application development.
Here is an output of example:
![output]()
Conclusion
In this article we learned the concept of the open close principal, I hope you have understood the concepts and implementation, comments are welcome always in case of a misunderstanding. In the next article we will discuss the next principal of SOLID.