S.O.L.I.D Design Principles Explained : Part 2

namespace BusinessLayer
{
public class DataFormatter
{
public virtual string FormatEmployeeData()
{
var dataAccess=new DataAccess();
Console.WriteLine("Getting Employee Data...");
var employessList = dataAccess.GetEmployeeData();
Console.WriteLine("Formatting the Employee details...");
return string.Format("Employee Name of Employee ID {0} is {1}",
employessList[0].EmployeeId, employessList[0].EmployeeName);
}
}
public class OracleDataFormatter:DataFormatter
{
public override string FormatEmployeeData()
{
var dataAccess = new OracleDataAccess();
Console.WriteLine("Getting Employee Data...");
var employessList = dataAccess.GetEmployeeData();

Console.WriteLine("Formatting the Employee details...");
return string.Format("Employee Name of Employee ID {0} is {1} and Designation of the Employee is {2}",

Next after formatting the data, we need to bind the data to display the new data. We now have to create a new class DisplayEmployeeOracleData with the method changed to specify that it overrides the method DisplayEmployeeData() in the child class. Now, I am going to inherit the class DisplayEmployee.

Now my code looks something like this:

using System;
namespace BusinessLayer
{
public class DisplayEmployee
{
public virtual void DisplayEmployeeData()
{
DataFormatter dataFormatter=new DataFormatter();
string empData = dataFormatter.FormatEmployeeData();
Console.WriteLine("Displaying Employee Data for Data grid as below:");
Console.WriteLine(empData);
}
}
public class DisplayEmployeeOracleData : DisplayEmployee
{
public override void DisplayEmployeeData()
{
DataFormatter dataFormatter = new OracleDataFormatter();
string empData = dataFormatter.FormatEmployeeData();
Console.WriteLine("Displaying Employee Data for Oracle Database as below:");
Console.WriteLine(empData);
}
}
}

Now I also need to change the EmployeeData class in the same way as we did the above:

using System.Linq;
using System.Text;

namespace BusinessLayer
{
public class EmployeeData
{
public virtual void DisplayEmployeeData()
{
DisplayEmployee displayEmployee = new DisplayEmployee();
displayEmployee.DisplayEmployeeData();
}
}
public class EmployeeOracleData : EmployeeData
{
public override void DisplayEmployeeData()
{
DisplayEmployee displayEmployee = new DisplayEmployeeOracleData();
displayEmployee.DisplayEmployeeData();
}
}
}

You observe that both the methods in the two classes EmployeeData and EmployeeOracleData have the DisplayEmployee type. But, have created an instance of the new class.

DisplayEmployee displayEmployee = new DisplayEmployeeOracleData();

The last change we need to make is in the Program.cs; the modified code is:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using BusinessLayer;

namespace SolidPrinciples
{
class Program
{
static void Main(string[] args)
{
EmployeeData employeeData = new EmployeeOracleData();
employeeData.DisplayEmployeeData();
Console.ReadLine();
}
}
}

Now you need to change the EmployeeData to EmployeeOracleData.

EmployeeData employeeData = new EmployeeOracleData();

Note: I have used the implicitly typed variable "VAR" in previous examples in Part 1. But, using Var will not help us in these examples to understand the concept and it may cause errors while casting the base class object to the child class object. Unless you are sure do not use Var in your code. It is always better to declare variables by class types.

Now run the program and see the output



So we finally added the new code by just modifying a small amount of code like adding a virtual keyword to the methods of the base class and overridde the methods in the child class and also type casting our base class objects with the child class and that's it, we have achieved the principle of OCP.

You can observe that we have not modified any of the existing methods or class's functionality. Their responsibility is still a single for each class and the method still functions as it previously functioned. So, finally we conclude OCP by saying that we are not changing the existing functionality and so we are not introducing bugs with our new code. Our new code was introduced without modifying the existing functionality. This ends the article Open/Closed principle.

Please find the code used for this article attached to the article. And also pay attention to the creation of objects by specifying explicitly typed variables like Base class name and do not follow what resharper tells you, to change it to implicitly typed variables. Also, in day-to-day projects we always define base classes with methods decorated with the Virtual keyword so that whatever modifications we did in this article need not be done.

Also you would find that I have modified the project to move the newly created classes to new files so that our code looks neat and clear.

Hope you like this article too. We will discuss the Liskov Substitution principle in the next article 3.