Definitions

Single Responsibility Principle:

1. "A class should have only one reason to change”
2. Every module or class should have responsibility over a single part of the functionality
provided by the software, and that responsibility should be entirely encapsulated by the class

Open/Closed Principle
1. “Software entities should be open for extension, but closed for modification”
2. The design and writing of the code should be done in a way that new functionality should be
added with minimum changes in the existing code
3. The design should be done in a way to allow the adding of new functionality as new classes,
keeping as much as possible existing code unchanged

Liskov Substitution Principle :

1. “objects in a program should be replaceable with instances of their sub-types without altering
the correctness of that program”
2. If a program module is using a Base class, then the reference to the Base class can be
replaced with a Derived class without affecting the functionality of the program module
3. We can also state that Derived types must be substitutable for their base types

Interface Segregation Principle

1. “Many client-specific interfaces are better than one general-purpose interface”
2.We should not enforce clients to implement interfaces that they don't use. Instead of creating
one big interface we can break down it to smaller interfaces

Dependency Inversion Principle

1. One should “depend upon abstractions, [not] concretions"
2. Abstractions should not depend on the details whereas the details should depend on
abstractions
3. High-level modules should not depend on low level modules

SOLID Design Principles

SOLID Acronym
S : Single Responsibility Principle
O : Open closed Principle
L : Liskov substitution Principle
I : Interface Segregation Principle (ISP)
D : Dependency Inversion Principle (DIP)

Single Responsibility Principle

namespace SRPDemo
{
interface IUser
{
bool Login(string username, string password);
bool Register(string username, string password, string email);
void LogError(string error);
bool SendEmail(string emailContent);
 }
}

Code after Single Responsibility Segregation

namespace SRPDemo
{
interface IUser
{
bool Login(string username, string password);
bool Register(string username, string password, string email);
}
interface ILogger
{
void LogError(string error);
}

interface IEmail
{
bool SendEmail(string emailContent);
}
}

Open/Close Principle

Code before Open Closed Principle

namespace OpenClosedDemo
{
public class Employee
{
Employee() { }
public Employee(int id, string name, string type)
{
this.ID = id;
this.Name = name;
this.EmployeeType = type;
}

public int ID { get; set; }

public string EmployeeType { get; set; }
public string Name { get; set; }

public decimal CalculateBonus(decimal salary)

{
if (this.EmployeeType == "Permanent")
return salary * .1M;
else
return salary * .05M;
}
}
}
namespace OpenClosedDemo
{
class Program
{
static void Main(string[] args)
{
Employee empJohn = new Employee(1, "John", "Permanent" );
Employee empJason = new Employee(2, "Jason", "Temp");

Console.WriteLine(string.Format("Employee {0} Bonus: {1}",

empJohn.ToString(),
empJohn.CalculateBonus(100000).ToString()));
Console.ReadLine();
}
}
}

Code after Open Closed Principle Implementation

namespace OpenClosedDemo
{
public abstract class Employee
{
public int ID { get; set; }
public string Name { get; set; }

public Employee()
{
}
public Employee(int id, string name )
{
this.ID = id; this.Name = name;
}
public abstract decimal CalculateBonus(decimal salary);

public override string ToString()

{
return string.Format("ID : {0} Name : {1}", this.ID, this.Name);
}
}

public class PermanentEmployee : Employee

{
public PermanentEmployee()
{}

public PermanentEmployee(int id, string name) : base(id, name)

{}
public override decimal CalculateBonus(decimal salary)
{
 return salary * .1M;
}
}

public class TemporaryEmployee : Employee

{
public TemporaryEmployee()
{}

public TemporaryEmployee(int id, string name) : base(id, name)

{}
public override decimal CalculateBonus(decimal salary)
{
return salary * .05M;
}
}
}

namespace OpenClosedDemo
{
class Program
{
static void Main(string[] args)
{
Employee empJohn = new PermanentEmployee(1, "John" );
Employee empJason = new TemporaryEmployee(2, "Jason" );

Console.WriteLine(string.Format("Employee {0} Bonus: {1}",

empJohn.ToString(),
empJohn.CalculateBonus(100000).ToString()));
Console.WriteLine(string.Format("Employee {0} Bonus: {1}",
empJason.ToString(),
empJason.CalculateBonus(150000).ToString()));
Console.ReadLine();
}
}
}

Pros & Cons

If we don’t follow SOLID Principles we

1. End up with tight or strong coupling of the code with many other modules/applications
2. Tight coupling causes time to implement any new requirement, features or any bug fixes and
some times it creates unknown issues
3. End up with a code which is not testable
4. End up with duplication of code
5. End up creating new bugs by fixing another bug
6. End up with many unknown issues in the application development cycle

Following SOLID Principles helps us to

1. Achieve reduction in complexity of code
2. Increase readability, extensibility and maintenance
3. Reduce error and implement Reusability
4. Achieve Better testability
5. Reduce tight coupling

Liskov Substitue Principle

namespace SOLID_PRINCIPLES.LSP
{
class Program
{
static void Main(string[] args)
{
Fruit fruit = new Orange();
Console.WriteLine(fruit.GetColor());
fruit = new Apple();
Console.WriteLine(fruit.GetColor());
}
}
public abstract class Fruit
{
public abstract string GetColor();
}
public class Apple : Fruit
{
public override string GetColor()
{
return "Red";
}
}
public class Orange : Fruit
{
public override string GetColor()
{
return "Orange";
}
}
}