SOLID Principles with Real World examples in C#
SOLID principles are formed by using
S Single Responsibility Principles (SRP)
O Open Closed Principle (OCP)
L Liskov’s Substitution Principle (LCP)
I Interface Segregation Principle (ISP)
D Dependency Inversion Principle (DIP)
S Single Responsibility Principles (SRP)
There should never be more than one reason for a class to change, to be precise one class should have only one responsibility
Single Responsibility Principles (SRP) Real world example,
A perfect match for SRP is Microservices, a Microservice will not contain functionalities other than the one it is designated to do,
Example
· Order Processing Service,
· Shipment Management Service,
· User Authentication Service,
· Catalogue List Service
class OrderProcessor
{
public void Process(Order order)
{
// Check inventory
// Reserve inventory
// Update order status
// Send confirmation email
}
}
The above class violates the SRP because it has more than one reason to change (e.g. if the confirmation email process changes, or if the inventory process changes). It would be better to separate these responsibilities into multiple classes each having their own responsibility.
O Open Closed Principle (OCP)
The software entities should open for extension but should closed for altering the original functionality
Open: The software entities should be open because for example the client code may in need to add additional fields for their own needs, in this case the client code may use the class (software entity we talked about) as a parent class to create inherited child classes to achieve their goal.
Closed: This is very essential because the original functionality is already compiled, baselined, stored in a library, so altering the original functionality may lead to adverse consequences to the software
Real time example for SOLID Open Closed Principle (OCP) in C#
Any software which allows plugin development, example Mozilla Firefox browser allows users to write the plugins to attach based on the users need they will attach, but it will never allow the user to alter the original functionality in browse.
For example here we are simply using the document type to determine the save path
class Program
{
static void Main(string[] args)
{
// Without OCP Example
WithoutOCP_Document _WithoutOCP_Document = new WithoutOCP_Document();
string SavePath = _WithoutOCP_Document.DocumentSavePath(DocumentType.Word);
Console.WriteLine(SavePath);
SavePath = _WithoutOCP_Document.DocumentSavePath(DocumentType.PDF);
Console.WriteLine(SavePath);
Console.ReadLine();
}
}
public enum DocumentType
{
PDF,
Word
}
public class WithoutOCP_Document
{
public string DocumentSavePath(DocumentType _DocumentType)
{
string SavePath = string.Empty;
if (_DocumentType == DocumentType.PDF)
{
SavePath = @"Files/PDF";
}
else if (_DocumentType == DocumentType.Word)
{
SavePath = @"Files/MSWord";
}
return SavePath;
}
}
The above code will work when the requirement is fixed and expecting no further changes
But the problem with the above code is:
1) What if I want to add one more document type?
2) Even if the program allows the logic to be modified by the client code then the testing needs to be done explicitly
3) If the developer is doing the changes for this addition, then the testing needs to be completed fully for all the classes involved
static void Main(string[] args)
{
string SavePath = string.Empty;
// With OCP Example
WithOCP_Document _WithOCP_Document;
_WithOCP_Document = new WordDocument();
SavePath = _WithOCP_Document.DocumentSavePath(DocumentType.Word);
Console.WriteLine(SavePath);
_WithOCP_Document = new PDFDocument();
SavePath = _WithOCP_Document.DocumentSavePath(DocumentType.PDF);
Console.WriteLine(SavePath);
Console.ReadLine();
}
}
public enum DocumentType
{
PDF,
Word
}
public class WithOCP_Document
{
public virtual string DocumentSavePath(DocumentType _DocumentType)
{
return string.Empty;
}
}
public class WordDocument : WithOCP_Document
{
public override string DocumentSavePath(DocumentType _DocumentType)
{
return @"Files/MSWord";
}
}
public class PDFDocument : WithOCP_Document
{
public override string DocumentSavePath(DocumentType _DocumentType)
{
return @"Files/PDF";
}
}
The above code satisfies all the rules specified, by using this code the client code can add any type of and any number of documents and save path of their own, this code will not change the original functionality but extending the existing functionality
C# program with abstract class to apply the Open Closed Principle (OCP) for SOLID Pattern
class Program
{
static void Main(string[] args)
{
string SavePath = string.Empty;
// With OCP Example with abstract class
WithOCP_DocumentAbs _WithOCP_DocumentAbs;
_WithOCP_DocumentAbs = new WordDocument2();
SavePath = _WithOCP_DocumentAbs.DocumentSavePath(DocumentType.Word);
Console.WriteLine(SavePath);
Console.ReadLine();
}
}
public enum DocumentType
{
PDF,
Word
}
public abstract class WithOCP_DocumentAbs
{
public virtual string DocumentSavePath(DocumentType _DocumentType)
{
return string.Empty;
}
}
public class WordDocument2 : WithOCP_DocumentAbs
{
public override string DocumentSavePath(DocumentType _DocumentType)
{
return @"Files/MSWord";
}
}
public class PDFDocument2 : WithOCP_DocumentAbs
{
public override string DocumentSavePath(DocumentType _DocumentType)
{
return @"Files/PDF";
}
}
The code can be found here
Additional Example:
class FileLogger
{
public void Log(string message)
{
// Write message to file
}
}The above class violates the OCP because to add a new logging mechanism, we would need to modify the class. A better approach would be to define an interface for logging and implement it in a separate class for each logging mechanism.
L Liskov’s Substitution Principle (LCP)
In Liskov’s terms Type T is extending to Subtype S and S should have all the functionalities that the Type T is having.
In Simple terms Liskov’s Substitution Principle suggests that the derived class must inherit all the qualities of the base class, so that the base class is no need to change anything if any extension is happening to it
So, in this case the derived class should be a proper substitute for the base class
This principle is widely called as the extension of the Open and Closed Principle
Example:
class Square : Rectangle
{
public int Width { set { base.Height = base.Width = value; } }
public int Height { set { base.Height = base.Width = value; } }
}
The above class violates the LSP because a square is not a rectangle and can't be used in the same way as a rectangle. The properties for width and height must be independent.
I Interface Segregation Principle (ISP)
A class should not be forced to implement interfaces it doesn't use.
interface IVehicle
{
void StartEngine();
void StopEngine();
void Fly();
void Swim();
}
The above interface violates the ISP because classes that don't fly or swim must implement the unnecessary methods. A better approach would be to split the interface into multiple interfaces.
High-level modules should not depend on low-level modules, but they should both depend on abstractions.
class OrderProcessor
{
private readonly IInventoryService _inventoryService;
public OrderProcessor(IInventoryService inventoryService)
{
_inventoryService = inventoryService;
}
}
The above class follows the DIP because it depends on an abstraction (the IInventoryService interface) rather than a concrete implementation (a specific inventory service class). This allows for more flexibility and maintainability by making it easy to switch out the inventory service implementation without affecting the OrderProcessor class.
For an excellent pictorial representation of SOLID please look this
Comments