SOLID Principles: A Quick Guide (.NET examples)

Recently, I was thinking about some topics for a short and knowledge-refreshing article. One subject that I rarely hear being talked about, but is really important in software development, are the SOLID principles. For a lot of experienced developers, these "rules" may seem pretty clear, yet I often come across code changes that don't follow these principles. Sometimes, I even find some that I've made myself, so no disrespect intended.

To enhance the value of this article, I've included some basic explanations and examples in C#

Single Responsibility Principle (SRP)

Each class should have one, and only one, reason to change. This means a class should only have one job.

Example:

public class Order
{
    public void CalculateTotalSum() { /*...*/ }
    public void GetItems() { /*...*/ }
    public void PrintOrder() { /*...*/ }
    public void ShowOrder() { /*...*/ }
}

This Order class violates SRP because it has more than one responsibility. A better approach is to split this into several classes, each handling a single concern.

---

Open-Closed Principle (OCP)

Software entities should be open for extension but closed for modification. This encourages stability while allowing system growth.

Example:

public class Rectangle
{
    public double Height { get; set; }
    public double Width { get; set; }
}
public class AreaCalculator
{
    public double TotalArea(Rectangle[] arrRectangles)
    {
        double area = 0;
        foreach (var objRectangle in arrRectangles)
        {
            area += objRectangle.Height * objRectangle.Width;
        }
        return area;
    }
}

In this example, if we want to add a new shape, we'd have to modify the AreaCalculator class, which violates OCP.

---

Liskov Substitution Principle (LSP)

This principle insists that subclasses must be substitutable for their base classes without affecting functionality.

Example:

public class Vehicle
{
    public virtual void StartEngine() { /*...*/ }
}

public class ElectricCar : Vehicle
{
    public override void StartEngine() { /*...*/ }
}

public class Bicycle : Vehicle
{
    public override void StartEngine() { /*...*/ }
}

Here, a Bicycle doesn't have an engine to start, so substituting a Vehicle with a Bicycle would cause issues, thus violating LSP. A better approach would be to have a separate class for vehicles with engines.

---

Interface Segregation Principle (ISP)

No client should be forced to depend on interfaces they do not use.

Example

public interface IWorker
{
    void Work();
    void Eat();
}

Here, if a robot implements IWorker, the Eat method is useless. This violates ISP. It's better to break this into two interfaces: IWorker and IEater.

---

Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules, but both should depend on abstractions. This reduces tight coupling.

Example:

public class Email
{
    public void SendEmail() { /*...*/ }
}
public class Notification
{
    private Email _email;
    public Notification()
    {
        _email = new Email();
    }
}

here, the Notification class is tightly coupled with the Email class. Using DIP, we can introduce an interface to decouple them.

---

Despite their importance in writing maintainable and scalable code, these principles are frequently overlooked. For me it was a short, simple and much needed refresher. Hopefully for any other reader too 😀
Feel free to comment your thoughts

Happy coding!