SOLID Principles in Software Design (With C# Examples)

Introduction

The SOLID principles are five design principles that make software easier to understand, maintain, and extend. They help you create systems that are modular, flexible, and decoupled.

Below is a structured breakdown of each principle with practical C# examples.

1. Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change, meaning it should have only one job or responsibility.

Why it’s important:
If a class does too many things, any change in one responsibility may affect other behaviors, making the system harder to maintain and test.

In practice: If a class handles both user authentication and logging, it violates SRP. These responsibilities should be separated.

Violation of SRP:

public class UserManager
{
    public void RegisterUser(string username, string password) { ... }
    public void Log(string message) { ... } // Logging should be separate
}

Compliant with SRP:

public interface ILogger
{
    void Log(string message);
}

public class UserManager
{
    private readonly ILogger _logger;

    public UserManager(ILogger logger)
    {
        _logger = logger;
    }

    public void RegisterUser(string username, string password)
    {
        // Registration logic
    }
}

public class Logger : ILogger
{
    public void Log(string message) { ... }
}

2. Open/Closed Principle (OCP)

Definition: Software entities should be open for extension but closed for modification.

Why it’s important: You should extend behavior without modifying existing code, reducing the risk of introducing new bugs.

Violation of OCP:

public class PaymentProcessor
{
    public void ProcessPayment(PaymentType type)
    {
        if (type == PaymentType.CreditCard) { ... }
        else if (type == PaymentType.PayPal) { ... }
        // Adding new methods requires modifying this class
    }
}

Compliant with OCP:

public interface IPaymentMethod
{
    void ProcessPayment();
}

public class CreditCardPayment : IPaymentMethod
{
    public void ProcessPayment() { ... }
}

public class PayPalPayment : IPaymentMethod
{
    public void ProcessPayment() { ... }
}

public class PaymentProcessor
{
    private readonly IPaymentMethod _paymentMethod;

    public PaymentProcessor(IPaymentMethod paymentMethod)
    {
        _paymentMethod = paymentMethod;
    }

    public void ProcessPayment()
    {
        _paymentMethod.ProcessPayment();
    }
}

3. Liskov Substitution Principle (LSP)

Definition: Objects of a superclass should be replaceable with objects of a subclass without breaking application behavior.

Why it’s important: Derived classes must honor the behavior expected from the base class.

Violation of LSP:

public class Bird
{
    public virtual void Fly() { ... }
}

public class Ostrich : Bird
{
    public override void Fly()
        => throw new InvalidOperationException("Cannot fly");
}

Compliant with LSP:

public class Bird
{
    public virtual void Move() { ... }
}

public class Sparrow : Bird
{
    public override void Move() { Fly(); }
    public void Fly() { ... }
}

public class Ostrich : Bird
{
    public override void Move() { Run(); }
    public void Run() { ... }
}

4. Interface Segregation Principle (ISP)

Definition: Clients should not be forced to depend on interfaces they do not use.

Why it’s important: Large, “fat” interfaces cause unnecessary implementation requirements.

Example: Instead of one large interface:

public interface IPaymentService
{
    void Validate();
    void Process();
    void GenerateReport();
}

Break it into smaller interfaces:

public interface IPaymentValidator
{
    void Validate();
}

public interface IPaymentProcessor
{
    void Process();
}

public interface IPaymentReporter
{
    void GenerateReport();
}

Classes implement only what they need.

5. Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions.

Why it’s important:
It reduces tight coupling and increases flexibility.

Violation of DIP:

public class DatabaseService
{
    private SqlConnection _connection;

    public DatabaseService()
    {
        _connection = new SqlConnection();
    }
}

Compliant with DIP:

public interface IDatabaseConnection
{
    void Connect();
}

public class SqlConnection : IDatabaseConnection
{
    public void Connect() { ... }
}

public class DatabaseService
{
    private readonly IDatabaseConnection _connection;

    public DatabaseService(IDatabaseConnection connection)
    {
        _connection = connection;
    }
}

Why SOLID Matters

Flexibility: Extend systems without breaking existing functionality.

Maintainability: Code becomes easier to manage as responsibilities are clearly separated.

Testability: Decoupled components can be independently unit tested.

Real-World Example in C# (E-commerce System)

If you’re building an e-commerce system:

• Use SRP to separate Order Processing and Payment Processing.

• Use OCP to add new payment methods without modifying the core processor.

• Follow LSP to ensure all payment types behave consistently.

• Apply ISP to split validation, processing, and reporting into separate interfaces.

• Use DIP so your system depends on payment abstractions, not specific APIs.

By following SOLID principles, you build software that is scalable, maintainable, extensible, and robust for long-term growth.