Solid Principles In C#

Jasbeer Singh
8y
8.8k
0
7

Blog

Solid Principles

The five basic principles of object oriented programming and design are named by Robert C. Martin. These are the guidelines to remove the code smell and provide flexibility in addition to providing an extensible program.

Definition

S Single Responsibility Principle
O Open Closed Principle
L Liskov Substitution principle
I Interface Segregation Principle
D Dependency Principle

Single Responsibility Principle

This principle states that a class or an entity should have only one responsibility. Classess having more than one responsibility violates the Single Responsibility principle. Let us understand this with an example: Let us have a Student class. This class should contain information about the student only.

public class Student
{
public string studentName { get; set; }
public string studentID { get; set; }
public void Insert()
{
//insert logic
}
public void Update()
{
//insert logic
}
public void Validate()
{
try
{
//Validate logic
}
catch (Exception ex)
{
//Write into log file if exception occurs
System.IO.File.WriteAllText("Log.txt", ex.ToString());
}
}
}

In student class, we have Validate method, which is doing log activity if any error occurs in the validate method. A Student class should only do student activities. If any error occurs in the log, we have to modify student class, which is not a good practice. This is a violation of the single responsibility principle and due to this, we need the single responsibility principle to be followed.

Open Closed Principle

This principle states that a class can be opened for the modification in the near future, which means there should be no difficulty while changing some functionality.

Suppose, if a class is having a limited functionality and after some days or years, we have to add some more functionality. In this case, we should not modify the working code but extend the class.

Let’s understand this with an example

The class given below is calculating the salary of two employees; i.e., Principal and teacher.

public class Salary
{
public decimal CalculateSal(string empType)
{
decimal salary = 0;
if (empType == "principle")
{
salary = 25000;
}
else if (empType == "Teacher")
{
salary = 10000;
}
return salary;
}
}

If after a few days or months or years, we need to calculate the salary of Peon also, for this, we have to add one more block for Peon. Thus, we have to change the core class for this. To avoid this, we should extend the class. To achieve this extension of class, we will create an abstract class with an abstract method CalculateSal. With this approach, if we need to calculate Peon's salary, we should not have to change the core class, but we will add a new class, which inherits from abstract class.

The code is given below to explain it..

//Abstract class Salary
public abstract class Salary
{
public abstract decimal CalculateSal(string empType);
}
//Principle class inhertis Salary class
public class Principle : Salary
{
public override decimal CalculateSal(string empType)
{
return 25000;
}
}
//Teacher class inhertis Salary class
public class Teacher : Salary
{
public override decimal CalculateSal(string empType)
{
return 10000;
}
}
//Peon class inhertis Salary class
public class Peon : Salary
{
public override decimal CalculateSal(string empType)
{
return 5000;
}
}

The code block given above creates an abstract class, where CalculateSal abstract method has been defined. Thus, if again we need to calculate the salary of some other type of employee, we should not have to change the core class but create an extra class for that employee and inherit it from Salary class (abstract class).

Liskov Substitution Principle

The Liskov Substitution principle states that an object in a program should be replaceable without changing the behavior of the program.

Derived classes must be extending the base class without changing its behavior. Let’s create class MiddleEmp that maintains the list of middle level employees.

public class MiddleEmp
{
List list = new List();
public virtual void AddStudents(Student obj)
{
list.Add(obj);
}
public int Count
{
get
{
return list.Count;
}
}
}

The AddStudents () method accepts an instance of Student and adds to the generic list. The Count property returns the number of Student elements in the list.

Now, there is another class TopEmp that inherits from MiddleEmp.

public class TopEmp : MiddleEmp
{
private int maxCount = 10;
public override void AddStudents(Student obj)
{
if (Count < maxCount)
{
AddStudents(obj);
}
else
{
throw new Exception("Only " + maxCount + " Student can be added.");
}
}
}

TopEmp class overrides the AddStudents() method of the MiddleEmp base class.The new implementation checks whether the Student count is less than maxCount. If so, the Student is added to the List else an exception is thrown.

MiddleEmp em = null;
em = new TopEmp();
for (int i = 0; i < 20; i++)
{
Student obj = new Student();
em.AddStudents(obj);
}

A variable of MiddleEmp class has been declared, which points to TopEmp class. The problem arises in for loop , where the for loop attempts to add 20 Students to topEmp but TopEmp allows only 10 instances and maxCount is 10. Hence, it throws an error.

If Object em would have been of MiddleEmp Class, then it would have added 20 students, but the code substitutes TopEmp in place of MiddleEmp, which throws an exception and it is against the Liskov Substitution principle.

Liskov example

public abstract class StudentCollection {
public abstract void AddStudent(Student obj);
public abstract int Count {
get;
}
}
public class MiddleEmp: StudentCollection {
List list = new List();
public override void AddStudent(Student obj) {
list.Add(obj);
}
public override int Count {
get {
return list.Count;
}
}
}
public class TopEmp: StudentCollection {
private int count = 0;
Student[] list = new Student[5];
public override void AddStudent(Student obj) {
if (count < 5) {
list[count] = obj;
count++;
} else {
throw new Exception("Only " + count + " Student can be added.");
}
}
public override int Count {
get {
return list.Length;
}
}
}
}
//new set of classes can then be used as follows:
Student s = new Student() {
StudentID = "123"
};
StudentCollection collection = null;
collection = new MiddleEmp();
collection.AddStudent(s);
collection = new TopEmp();
collection.AddStudent(s);

Interface Segregation Principle

Interface Segregation means segregating the interface as per use. The class should not be forced to access the method, as it doesn’t need to use it.

Suppose we have an interface IEmployee, which is being used by an Employee class and student class. First, we had method- Add in the interface. Now, if our employee wants another method, DeleteEmp for Employees class, we should not Include it into the IEmployee Interface, rather we should create another interface for it. If we include it in the IEmployee interface, we have to use it in Student class also because we are implementing the interface there.

The code given below presents the view of Interface Segregation.

interface IEmployee
{
void Add();
void DeleteEmp();
}
interface IEmpDel : IEmployee
{
void DeleteEmp();
}
//Class Employee that needs Both Add and Delete methods
class Employee : IEmployee, IEmpDel
{
public void Add()
{
Employee obj = new Employee();
obj.Add();
}
public void Delete()
{
Employee obj = new Employee();
obj.Delete();
}
}
//Student that doesn't needs Delete Method
class Student : IEmployee
{
public void Add()
{
Student obj = new Student();
obj.Add();
}
}

DEPENDENCY INVERSION PRINCIPLE

Dependency Inversion Principle states that the high level modules should not depend on the low level modules, but both should depend on abstraction.

An abstraction layer must be between the low level modules and high level modules.

We have a Management class, which is a high level class and the class called Employee is the low level class. We need to add a new low level class called Student. Management class is very complex and now, we have to change it for student class, which will be very difficult, as it will take a long time because of the complexity and some functionality may be affected.

class Employee
{
public void Add()
{
// ....working
}
}
class Management
{
Employee emp;
public void Adding(Employee e)
{
emp = e;
}
public void manage()
{
emp.Add();
}
}
class Student
{
public void Add()
{
//....Adding
}
}

To overcome this, we add a layer of abstraction, where low level and high level will not depend on each other but on an abstraction.

The code is given below, where Dependency Inversion Principle is followed.

We will add an interface to implement by these two classes, Employee and Student. Now, if we add a class Student, management class will not find anything difficult by adding any new class, as management class doesn’t require any change for it. We are just using the interface as a middle layer between High level class and Low level classes.