SOLID Principles in C# Explained: Definitions, Examples & Best Practices

When you begin learning C# or building real-world .NET applications, you quickly notice that writing clean, maintainable code is challenging. This is exactly why the SOLID principles exist. These rules help developers write software that is easier to understand, safer to modify, and simpler to test.

In this guide, we will gradually explore each SOLID principle using clear explanations and C# examples. Additionally, for every principle we will compare a bad implementation with the correct version, making the learning process much smoother.

What Are the SOLID Principles?

Before we dive deeper, it’s important to understand what SOLID represents.
SOLID is an acronym created by Robert C. Martin (Uncle Bob) and includes five essential principles:

• S — Single Responsibility
• O — Open/Closed
• L — Liskov Substitution
• I — Interface Segregation
• D — Dependency Inversion

Now, let’s explore each principle step by step.

1. Single Responsibility Principle (SRP)

To begin, the Single Responsibility Principle suggests that every class should focus on just one task.
When a class tries to handle too many responsibilities, it becomes difficult to test and prone to bugs.
By keeping responsibilities separated, your code becomes more organized and maintainable.
Simply put, one class should do one thing only.

❌ Bad Example (Violating SRP)

public class InvoiceService
{
    public void CreateInvoice() { }
    public void SendEmail(string email) { }
    public void SaveToDatabase() { }
}

However, this class mixes three unrelated responsibilities, making it fragile and harder to update.

✅ Good Example (SRP Applied)

public class InvoiceCreator
{
    public void CreateInvoice() { }
}

public class EmailService
{
    public void SendEmail(string email) { }
}

public class InvoiceRepository
{
    public void SaveToDatabase() { }
}

Now each class does exactly one job, which makes the system more modular and easier to manage.

2. Open/Closed Principle (OCP)

Next, the Open/Closed Principle teaches us that classes should be open for extension but closed for modification.
This means you should be able to add new features without altering existing code.
This avoids introducing new bugs into working logic.
In other words, extend behavior — don’t rewrite it.

❌ Bad Example (Violating OCP)

public class DiscountService
{
    public double GetDiscount(string type, double price)
    {
        if (type == "Regular") return price * 0.1;
        if (type == "VIP") return price * 0.2;
        return 0;
    }
}

As you can see, every time we add a new discount type, we must modify this method — a direct violation of OCP.

✅ Good Example (OCP Applied)

public interface IDiscountStrategy
{
    double ApplyDiscount(double price);
}

public class RegularCustomerDiscount : IDiscountStrategy
{
    public double ApplyDiscount(double price) => price * 0.1;
}

public class VipCustomerDiscount : IDiscountStrategy
{
    public double ApplyDiscount(double price) => price * 0.2;
}

public class DiscountService
{
    private readonly IDiscountStrategy _strategy;
    public DiscountService(IDiscountStrategy strategy) => _strategy = strategy;

    public double GetDiscount(double price) => _strategy.ApplyDiscount(price);
}

With this design, you only need to create a new discount class whenever new behavior is required — no modifications needed.

3. Liskov Substitution Principle (LSP)

Moving forward, the Liskov Substitution Principle ensures that child classes can safely replace their parent classes.
A subclass must behave consistently with what the parent class promises.
If a child class breaks expectations or throws strange exceptions, it violates LSP.
This principle keeps inheritance predictable and reliable.

❌ Bad Example (Violating LSP)

public class Bird
{
    public virtual void Fly() => Console.WriteLine("Flying...");
}

public class Penguin : Bird
{
    public override void Fly()
    {
        throw new NotSupportedException("Penguins cannot fly!");
    }
}

This example breaks LSP because a « Penguin » cannot logically replace a « Bird » that is expected to fly.

✅ Good Example (LSP Applied)

public abstract class Bird { }

public interface IFlyingBird
{
    void Fly();
}

public class Sparrow : Bird, IFlyingBird
{
    public void Fly() => Console.WriteLine("Flying...");
}

public class Penguin : Bird
{
    // Penguins do not fly — so no Fly() method
}

With this structure, flying and non-flying birds are clearly separated, and inheritance becomes safe

4. Interface Segregation Principle (ISP)

In addition, the Interface Segregation Principle encourages us to create focused and lightweight interfaces.
Classes should not be forced to implement methods they do not need.
Large, bloated interfaces make code harder to use and maintain.
Therefore, breaking interfaces into logical groups keeps everything clean and flexible.

❌ Bad Example (Violating ISP)

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

public class Robot : IWorker
{
    public void Work() { }
    public void Eat() => throw new NotImplementedException();
}

Here, the robot is forced to implement a method that makes no sense for its behavior.

✅ Good Example (ISP Applied)

public interface IWorkable { void Work(); }
public interface IEatable { void Eat(); }

public class Human : IWorkable, IEatable
{
    public void Work() { }
    public void Eat() { }
}

public class Robot : IWorkable
{
    public void Work() { }
}

Now each class implements only the methods that are relevant to it — exactly what ISP recommends.

5. Dependency Inversion Principle (DIP)

Finally, the Dependency Inversion Principle states that high-level modules should depend on abstractions, not concrete classes.
By depending on interfaces, your application becomes more flexible and testable.
Low-level classes should also depend on abstractions, not specific implementations.
This principle forms the foundation of modern Dependency Injection in .NET.

❌ Bad Example (Violating DIP)

public class FileLogger
{
    public void Log(string message) { }
}

public class OrderService
{
    private FileLogger logger = new FileLogger();

    public void PlaceOrder()
    {
        logger.Log("Order placed");
    }
}

This creates tight coupling, meaning you cannot easily switch to another logger like a database or cloud logger.

✅ Good Example (DIP Applied)

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

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

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

public class OrderService
{
    private readonly ILogger _logger;

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

    public void PlaceOrder()
    {
        _logger.Log("Order placed");
    }
}

Now your service depends on an interface, making it easy to replace one logger with another without changing the code.

Conclusion

To sum up, the SOLID principles are essential for writing clean, professional, and maintainable C# code. They help you avoid complexity, reduce bugs, and build systems that scale over time.

Here’s a quick recap:

By consistently applying these principles, you will write code that is easier to test, reuse, and evolve — exactly how modern .NET applications should be built.

More resources :

Learn microsoft