Solid Principles in C#.net

15 Jun 2023

In C#, the SOLID principles are a set of guidelines that help developers design software that is modular, maintainable, and extensible. SOLID is an acronym that stands for:

S – Single Responsibility Principle (SRP)

O – Open-Closed Principle (OCP)

L – Liskov Substitution Principle (LSP)

I – Interface Segregation Principle (ISP)

D – Dependency Inversion Principle (DIP)

Single Responsibility Principle (SRP):

A class should have only one reason to change. It states that a class should have only one responsibility or job. This principle helps to keep classes focused, maintainable, and easier to understand.

public interface INotificationService
{
void SendNotification(string message);
}
public class EmailNotificationService : INotificationService
{
public void SendNotification(string message)
{
// Code to send an email notification
}
}
public class SMSNotificationService : INotificationService
{
public void SendNotification(string message)
{
// Code to send an SMS notification
}
}
public class NotificationSender
{
private readonly INotificationService _notificationService;

public NotificationSender(INotificationService notificationService) { _notificationService = notificationService; } public void SendNotification(string message) { _notificationService.SendNotification(message); }

}

In this example, the FileManager class has the responsibility of reading and saving files, while the FileParser class is responsible for parsing files. Each class has a single responsibility, making it easier to understand and maintain.

Open-Closed Principle (OCP):

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This principle encourages designing modules that can be extended without modifying their existing code, reducing the risk of introducing bugs and making it easier to add new features.

public abstract class Shape
{
public abstract double CalculateArea();
}
public class Rectangle : Shape
{
public double Width { get; set; }
public double Height { get; set; }
public override double CalculateArea() { return Width * Height; }
}
public class Circle : Shape
{
public double Radius { get; set; }
public override double CalculateArea() { return Math.PI * Radius * Radius; }
}

In this example, the Shape class is open for extension, as new shapes can be added by creating new subclasses of Shape. The existing code is closed for modification, as the Shape class and its existing subclasses do not need to be changed when adding new shapes.

Liskov Substitution Principle (LSP):

Objects of a superclass should be able to be replaced with objects of their subclass without breaking the behavior of the system. In other words, derived classes should be substitutable for their base classes, and they should honor the contracts defined by the base class.

public class Vehicle
{
public virtual void Start()
{
Console.WriteLine(“Starting the vehicle”);
}
}
public class Car : Vehicle
{
public override void Start()
{
Console.WriteLine(“Starting the car”);
}
}
public class Motorcycle : Vehicle
{
public override void Start()
{
Console.WriteLine(“Starting the motorcycle”);
}
}

In this example, the Car and Motorcycle classes are subclasses of Vehicle, and they can be substituted for Vehicle without breaking the behavior of the system. The Start method is overridden in each subclass, providing specific implementations for starting a car and starting a motorcycle.

Interface Segregation Principle (ISP):

Clients should not be forced to depend on interfaces they do not use. This principle encourages the creation of small, specific interfaces instead of large general-purpose interfaces. It helps to avoid forcing clients to implement methods they don’t need and promotes decoupling and flexibility.

public interface IOrder
{
void ProcessOrder();
}
public interface IShipping
{
void ShipOrder();
}
public class OnlineOrder : IOrder, IShipping
{
public void ProcessOrder()
{
Console.WriteLine(“Processing online order”);
}
public void ShipOrder() { Console.WriteLine("Shipping online order"); }
}
public class OfflineOrder : IOrder
{
public void ProcessOrder()
{
Console.WriteLine(“Processing offline order”);
}
}

In this example, we have two interfaces: IOrder and IShipping. The OnlineOrder class implements both interfaces, as it can process an order and ship it. The OfflineOrder class only implements the IOrder interface because it doesn’t involve shipping. This segregation of interfaces ensures that classes only depend on the methods they actually need.

Dependency Inversion Principle (DIP):

High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. This principle promotes loose coupling between modules, promotes modular design, and enables easier testing and maintainability.

public NotificationSender(INotificationService notificationService) { _notificationService = notificationService; } public void SendNotification(string message) { _notificationService.SendNotification(message); }

}

In this example, the NotificationSender class depends on the INotificationService interface rather than concrete implementations. This allows different notification services to be injected at runtime, promoting loose coupling. The high-level module (NotificationSender) depends on the abstraction (INotificationService) rather than the low-level modules (EmailNotificationService, SMSNotificationService).

By adhering to these principles, developers can create code that is easier to understand, maintain, and modify, leading to more robust and scalable software systems.

Social tagging: C# DOTNET > OOPS CONCEPT

Maria academy

Solid Principles in C#.net

Recent Posts

Categories