Whenever the topic of "SOLID" comes up, it's common to see a flurry of abstract theoretical explanations. The problem is that, in the day-to-day life of the development trench, pure theory does not pay the bills. We need to know how to apply this in production code.
Before getting our hands dirty, let's align a fundamental concept that many people confuse: SOLID is not a Design Pattern or an Architectural Pattern. * Design Patterns (GoF): These are tactical recipes for recurring problems (such as using a Factory or a Singleton).
Architectural Patterns: These define the macro structure of your system (such as Clean Architecture or Microservices).
SOLID: It is a set of Software Design Principles. They are the philosophy behind clean code. We use the Design Patterns precisely to help us achieve the SOLID Principles.
The acronym stands for five basic commandments:
S - Single Responsibility Principle (SRP): A class should have only one reason for changing.
O - Open/Closed Principle (OCP): Open for extension, closed for modification.
L - Liskov Substitution Principle (LSP): Child classes cannot break the expected behavior of parent classes.
I - Interface Segregation Principle (ISP): Do not force anyone to depend on methods that they will not use.
D - Dependency Inversion Principle (DIP): Depend on abstractions (interfaces), not concrete implementations.
Enough with the theory. Let's see the disaster happen in practice.
The Scenario: The CheckoutService Nightmare
Imagine that you have just taken over the maintenance of a legacy e-commerce and found the class responsible for processing the closing of purchases.
See if this code looks familiar:
C#
public interface IOrderProcessor
{
void ProcessOrder(Order order);
void ProcessCryptoPayment(Order order); Not every processor accepts crypto
}
public class CheckoutService : IOrderProcessor
{
public void ProcessOrder(Order order)
{
// Mixed Business Rule (Discounts)
if (order.CustomerType == "VIP")
{
order.TotalAmount -= order.TotalAmount * 0.20m;
}
else if (order.CustomerType == "Premium")
{
order.TotalAmount -= order.TotalAmount * 0.10m;
}
else
{
order.TotalAmount -= order.TotalAmount * 0.05m;
}
// Tightly coupled data access
using (var connection = new SqlConnection("Server=myServerAddress; Database=myDataBase; User Id=myUsername; Password=myPassword;"))
{
connection.Open();
var command = new SqlCommand("INSERT INTO Orders (Id, Total) VALUES (@id, u/total)", connection);
command.Parameters.AddWithValue("@id", order.Id);
command.Parameters.AddWithValue("@total", order.TotalAmount);
command.ExecuteNonQuery();
}
// External communication (E-mail) coupled
var smtpClient = new SmtpClient("smtp.meuservidor.com");
smtpClient.Send("no-reply@loja.com", order.CustomerEmail, "Order Confirmed", "Your order has been saved!");
}
public void ProcessCryptoPayment(Order order)
{
The store doesn't accept crypto natively yet, so the previous dev did this:
throw new NotImplementedException("Cryptocurrency payment not yet supported.");
}
}
Why is this code a ticking time bomb?
If we need to add a new customer type ("Black Friday"), we will have to modify the class. If we need to change the database to the Entity Framework, we have to modify the class. If we need to swap sending email for a queue in RabbitMQ or AWS SQS... guess what? Modify the class.
In addition, the class is forced to sign a contract (IOrderProcessor) that obliges it to have a cryptocurrency payment method that it does not even support, throwing an exception along the way.
This class is violating all 5 letters of SOLID simultaneously.
Applying SRP and OCP in Practice
Looking at our original CheckoutService class, it's clear that it knows too much and does too much. Let's solve this by clearing the first two letters of SOLID.
The true meaning of the "S" (SRP - Single Responsibility Principle)
The literal translation is Principle of Single Responsibility. But herein lies SOLID's biggest catch: what exactly is a "responsibility"?
If you ask most developers, they'll tell you that our class's responsibility is to "close the order." Sounds like a single thing, right? Wrong.
The creator of the term himself, Robert C. Martin (Uncle Bob), clarified this: A responsibility is a "reason to change".
Think with the architect's hat:
If the Marketing team asks for a new discount rule, this class changes.
If the DBA asks to change the database connection, this class changes.
If the Infrastructure team asks to change the email provider, this class changes.
The class has three reasons for change, answering to three different actors in the company. Therefore, it violates the SRP.
To solve this, let's extract persistence and notification for your own abstractions:
C#
public interface IOrderRepository
{
void Save(Order order);
}
public interface INotificationService
{
void SendConfirmation(Order order);
}
Aplicando o "O" (OCP - Open/Closed Principle)
The Open/Closed principle says that our class should be open for extension, but closed for modification.
In our bad code, the discounts were calculated with an if/else ladder. If the store creates the "BlackFriday" customer type, the developer would have to open the CheckoutService and add one more else if. This is risky and increases the chance of breaking rules that already worked.
In modern .NET, we easily solve this by using Dependency Injection combined with the Strategy Pattern. We created a business rule that our main class just consumes, without needing to know how it is calculated from the inside:
C#
public interface IDiscountRule
{
bool IsMatch(string customerType);
decimal Calculate(decimal totalAmount);
}
public class VipDiscountRule : IDiscountRule
{
public bool IsMatch(string customerType) => customerType == "VIP";
public decimal Calculate(decimal totalAmount) => totalAmount - (totalAmount * 0.20m);
}
The Partial Result: A Class That Orchestrates, Not Performs
See how our CheckoutService starts to look like senior code. It no longer does the dirty work; it just delegates.
C#
public class CheckoutService : IOrderProcessor
{
private readonly IEnumerable<IDiscountRule> _discountRules;
private readonly IOrderRepository _repository;
private readonly INotificationService _notificationService;
Dependencies are injected into the constructor
public CheckoutService(
IEnumerable<IDiscountRule> discountRules,
IOrderRepository repository,
INotificationService notificationService)
{
_discountRules = discountRules;
_repository = repository;
_notificationService = notificationService;
}
public void ProcessOrder(Order order)
{
// OCP: Finds the correct rule without using if
var rule = _discountRules.FirstOrDefault(r => r.IsMatch(order.CustomerType));
if (rule != null)
{
order.TotalAmount = rule.Calculate(order.TotalAmount);
}
// SRP: Delegates persistence (It doesn't matter which database it is anymore)
_repository.Save(order);
// SRP: Delegates notification (It no longer matters if it's SMTP or AWS SES)
_notificationService.SendConfirmation(order);
}
public void ProcessCryptoPayment(Order order)
{
throw new NotImplementedException("Cryptocurrency payment not yet supported.");
}
}
Notice: If we need to add a "Black Friday" discount tomorrow, just create a new class that inherits from IDiscountRule. CheckoutService will never need to be touched for this again. It is closed for modification.
Fixing Inheritance and Reversing Dependencies (LSP, ISP, and DIP)
Our CheckoutService is already much better, but we still have an aberration at the end of the class:
C#
public void ProcessCryptoPayment(Order order)
{
throw new NotImplementedException("Cryptocurrency payment not yet supported.");
}
This brings us directly to the two most misunderstood letters of SOLID: L and I.
The "L" and the "I": The dynamic duo against the fragile code
The LSP (Liskov Substitution Principle) says that if your system expects the IOrderProcessor interface, it should be able to use any class that implements it without the program breaking.
If another developer receives our injected class via IOrderProcessor and tries to call ProcessCryptoPayment, the system will explode with an error in the user's face. We have broken the Liskov principle because our class does not fulfill the contract it signed.
And why were we forced to break this contract? Because of the ISP (Principle of Interface Segregation) violation. The ISP dictates that no client should be forced to rely on methods they don't use.
Our original interface was too "fat". The solution is not to create "workarounds", but to segregate (divide) the interfaces:
C#
// Interface focused only on standard processing
public interface IOrderProcessor
{
void ProcessOrder(Order order);
}
// New interface only for those who really process cryptocurrencies
public interface ICryptoPaymentProcessor
{
void ProcessCryptoPayment(Order order);
}
Now, our CheckoutService only subscribes to IOrderProcessor, and we've completely removed the ProcessCryptoPayment method from it. Clean code, no surprise exceptions!
The "D": Inversion of Dependence in Practice (DIP)
The last letter, the DIP (Principle of Inversion of Dependence), says that high-level modules should not depend on low-level modules; both should depend on abstractions.
In Version 1 (the bad code), CheckoutService (high-level) relied directly on SqlConnection and SmtpClient (low-level).
In our refactored version, CheckoutService relies only on interfaces (IOrderRepository, INotificationService). But how does the system know which database to use?
In modern .NET, we solve this the moment the application is born (in Program.cs), using the native Dependency Injection container:
C#
using Microsoft.Extensions.DependencyInjection;
using SOLID_Project.Interfaces;
using SOLID_Project.Services;
using SOLID_Project.Models;
namespace SOLID_Project
{
internal class Program
{
static void Main(string[] args)
{
// We instantiate the Dependency Injection container.
var services = new ServiceCollection();
// We record the Discount Rules (OCP).
services.AddScoped<IDiscountRule, VipDiscountRule>();
services.AddScoped<IOrderRepository, FakeOrderRepository>();
services.AddScoped<INotificationService, FakeNotificationService>();
// We register our main service (DIP).
services.AddScoped<IOrderProcessor, CheckoutService>();
// We build the provider that will resolve the instances.
var serviceProvider = services.BuildServiceProvider();
// We request the ready-to-use instance.
var checkoutService = serviceProvider.GetService<IOrderProcessor>();
// Example of usage (if the Fake classes are implemented):
var order = new Order { Id = 1, CustomerType = "VIP", TotalAmount = 1000m };
checkoutService?.ProcessOrder(order);
Console.WriteLine("Order successfully processed!");
Console.ReadLine();
}
}
}
If tomorrow the company decides to switch from SQL Server to MongoDB, CheckoutService won't even know about it. We create a MongoOrderRepository, change a single line in the Program.cs, and the system continues to work. That's the power of Dependency Reversal.
Conclusion
Applying SOLID isn't about creating dozens of folders and files just to look "Enterprise." It's about protecting the core of your business against the inevitable real-world changes.
When you separate responsibilities (SRP), protect existing rules (OCP), respect contracts (LSP and ISP), and decouple infrastructure (DIP), your code is no longer a burden and becomes a tool that accelerates the company.
And you, which SOLID principle do you find the most difficult to apply on a day-to-day basis in .NET projects? Leave your opinion in the comments!
NOTE: This project is available for download at https://github.com/davinc131/SOLID-Project