As software development progresses, applying established design principles is crucial for building maintainable, scalable, and flexible systems. SOLID principles are a set of five guidelines that help developers create clean, structured, and adaptable code. Ignoring these principles can lead to tightly coupled, rigid, and error-prone applications. In this article, we’ll explore each of the SOLID principles — Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion — by examining bad code examples, explaining the pitfalls, and refactoring them to follow best practices in .NET 9.

1. Single Responsibility Principle (SRP)

Modularity: A class should have only one reason to change.

The Single Responsibility Principle (SRP) states that a class should have only one responsibility, or in other words, it should focus on one specific task. Ignoring SRP leads to monolithic classes that are difficult to understand, maintain, and test. Let’s look at a bad code example and refactor it to follow SRP.

Anti-Pattern

This class violates SRP by combining two distinct responsibilities — employee management and report generation. If report generation needs to change, you’ll have to modify the same class that handles employee logic, increasing the risk of bugs and making the class harder to maintain over time.

public class EmployeeService
{
    public void AddEmployee(Employee employee) 
    {
        // Logic to add employee to database
    }

    public void GenerateReport(Employee employee)
    {
        // Logic to generate employee report
    }
}

Best Practice

Now, the EmployeeService is focused solely on managing employees, while the ReportService handles report generation. These two classes can now evolve independently, making them easier to maintain and reducing the likelihood of introducing bugs when making changes.

public class EmployeeService
{
    public void AddEmployee(Employee employee)
    {
        // Logic to add employee to database
    }
}

public class ReportService
{
    public void GenerateReport(Employee employee)
    {
        // Logic to generate employee report
    }
}

2. Open-Closed Principle (OCP)

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

The Open-Closed Principle encourages developers to write code that can be extended without modifying the original source. Ignoring OCP can lead to a situation where every new feature requires altering existing classes, increasing the risk of unintentionally breaking something.

Anti-Pattern

Each time a new payment method is introduced, we must modify the ProcessPayment method. This violates OCP because we’re constantly changing the class to add new functionality, increasing the risk of breaking existing code.

public class PaymentProcessor
{
    public void ProcessPayment(string paymentType)
    {
        if (paymentType == "CreditCard")
        {
            // Process credit card payment
        }
        else if (paymentType == "PayPal")
        {
            // Process PayPal payment
        }
        else if (paymentType == "Bitcoin")
        {
            // Process Bitcoin payment
        }
    }
}

Best Practice

Now, new payment methods can be added by extending the PaymentMethod class, without modifying the existing PaymentProcessor logic. This makes the codebase more maintainable and scalable while adhering to OCP.

public abstract class PaymentMethod
{
    public abstract void ProcessPayment();
}

public class CreditCardPayment : PaymentMethod
{
    public override void ProcessPayment()
    {
        // Process credit card payment
    }
}

public class PayPalPayment : PaymentMethod
{
    public override void ProcessPayment()
    {
        // Process PayPal payment
    }
}

public class PaymentProcessor
{
    public void ProcessPayment(PaymentMethod paymentMethod)
    {
        paymentMethod.ProcessPayment();
    }
}

3. Liskov Substitution Principle (LSP)

Polymorphism: Derived classes must be substitutable for their base classes.

The Liskov Substitution Principle ensures that subclasses can be used in place of their base classes without causing unexpected behavior. Violating LSP can lead to fragile code that breaks when a subclass doesn’t behave as expected.

Anti-Pattern

In this example, GiftCardPayment violates LSP because it behaves differently from the CreditCardPayment class by introducing a limit on the payment amount. The base class Payment does not expect this constraint, so when a GiftCardPayment is substituted where a Payment is expected, the system might throw unexpected exceptions.

public class Payment
{
    public virtual void Process(decimal amount)
    {
        // Logic for processing a payment
    }
}

public class CreditCardPayment : Payment
{
    public override void Process(decimal amount)
    {
        // Process credit card payment
        Console.WriteLine($"Processed Credit Card Payment of {amount}.");
    }
}

public class GiftCardPayment : Payment
{
    public override void Process(decimal amount)
    {
        if (amount > 100)
        {
            throw new InvalidOperationException("Gift card limit exceeded.");
        }
        Console.WriteLine($"Processed Gift Card Payment of {amount}.");
    }
}

Best Practice

In this refactored example, we use an interface IPayment instead of a base class, allowing each payment type to implement its own logic without forcing a direct inheritance relationship. This decouples the two payment types, respecting LSP because GiftCardPayment now makes its limitations explicit without breaking the expectations set by the base class.

By using an interface, each class can implement its own rules while keeping the expectations of the IPayment interface clear. The payment processor no longer relies on inheritance and can handle each payment type appropriately. This way, no assumptions about behavior are broken, and LSP is respected.

public interface IPayment
{
    void Process(decimal amount);
}

public class CreditCardPayment : IPayment
{
    public void Process(decimal amount)
    {
        // Process credit card payment
        Console.WriteLine($"Processed Credit Card Payment of {amount}.");
    }
}

public class GiftCardPayment : IPayment
{
    private const decimal MaxGiftCardAmount = 100;

    public void Process(decimal amount)
    {
        if (amount > MaxGiftCardAmount)
        {
            throw new InvalidOperationException("Gift card limit exceeded.");
        }
        Console.WriteLine($"Processed Gift Card Payment of {amount}.");
    }
}

4. Interface Segregation Principle (ISP)

Composability: Clients should not be forced to depend on methods they do not use.

The Interface Segregation Principle (ISP) encourages creating small, focused interfaces that are relevant to the clients that use them. Instead of having large, monolithic interfaces with multiple methods that not all clients need, ISP advocates for breaking them down into smaller, more specific interfaces. This allows each class to implement only the methods it actually needs, preventing unnecessary dependencies and making the code more flexible and easier to maintain.

Anti-Pattern

Here, both InkjetPrinter and LaserPrinter are forced to implement the Print3DModel method even though it’s irrelevant to their functionality. This violates ISP because the printers are forced to implement unnecessary methods that they will never use, leading to code that is harder to maintain and more prone to errors. Additionally, this forces the developers to add exception handling or leave unimplemented methods, which makes the design messy.

This violates the principle because each printer is not focused on the specific actions it should perform. Instead, it is tied to a general interface that forces it to implement behavior it doesn’t need.

public interface IPrinter
{
    void PrintDocument(string document);
    void Print3DModel(string model);  // Not relevant for most printers
}

public class InkjetPrinter : IPrinter
{
    public void PrintDocument(string document)
    {
        Console.WriteLine("Printing document on Inkjet Printer.");
    }

    public void Print3DModel(string model)
    {
        // This doesn't make sense for an inkjet printer
        throw new NotImplementedException("Inkjet printer cannot print 3D models.");
    }
}

public class LaserPrinter : IPrinter
{
    public void PrintDocument(string document)
    {
        Console.WriteLine("Printing document on Laser Printer.");
    }

    public void Print3DModel(string model)
    {
        // This doesn't make sense for a laser printer either
        throw new NotImplementedException("Laser printer cannot print 3D models.");
    }
}

Best Practice

Now, each printer class only implements the interfaces that are relevant to it. The InkjetPrinter and LaserPrinter only implement IPrinter, and the 3DPrinter implements both IPrinter and I3DPrinter. This keeps each class focused on the functionality it is supposed to perform, respecting ISP and eliminating the need for irrelevant methods to be implemented.

This approach not only makes the design more modular and easier to maintain but also makes it clear which printer types support which functionality, without forcing any class to deal with methods it doesn’t need.

Now, if a new type of printer is introduced, it only needs to implement the interfaces that are pertinent to its capabilities. For example, if you introduce a FaxPrinter, it would only implement the IPrinter interface, ensuring that each printer is focused on a specific task.

public interface IPrinter
{
    void PrintDocument(string document);
}

public interface I3DPrinter
{
    void Print3DModel(string model);
}

public class InkjetPrinter : IPrinter
{
    public void PrintDocument(string document)
    {
        Console.WriteLine("Printing document on Inkjet Printer.");
    }
}

public class LaserPrinter : IPrinter
{
    public void PrintDocument(string document)
    {
        Console.WriteLine("Printing document on Laser Printer.");
    }
}

public class 3DPrinter : IPrinter, I3DPrinter
{
    public void PrintDocument(string document)
    {
        Console.WriteLine("Printing document on 3D Printer.");
    }

    public void Print3DModel(string model)
    {
        Console.WriteLine("Printing 3D model on 3D Printer.");
    }
}

5. Dependency Inversion Principle (DIP)

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

The Dependency Inversion Principle (DIP) helps decouple components in your system by making high-level modules independent of the low-level details. Instead of having high-level modules directly depend on low-level modules, you create abstractions (interfaces or abstract classes) that both high-level and low-level modules depend on. This promotes loose coupling and increases the flexibility and maintainability of your codebase.

Anti-Pattern

In this example, the NotificationService class is tightly coupled to the EmailService class. If you want to change the way notifications are sent, say by adding a text message service or switching to a push notification system, you’ll have to modify the NotificationService class itself. This creates maintenance challenges and reduces flexibility because you’re forced to change high-level code when low-level details change. It also makes unit testing more difficult, as you’ll need to instantiate the EmailService class directly in your tests.

public class EmailService
{
    public void SendEmail(string message)
    {
        Console.WriteLine("Sending email: " + message);
    }
}

public class NotificationService
{
    private EmailService _emailService;

    public NotificationService()
    {
        _emailService = new EmailService();  // Directly depends on EmailService
    }

    public void SendNotification(string message)
    {
        _emailService.SendEmail(message);
    }
}

Best Practice

Now, the NotificationService depends on the abstraction INotificationChannel, not the concrete EmailService. This means you can pass any implementation of INotificationChannel (e.g., SMSService, PushNotificationService, etc.) into the constructor of NotificationService, allowing you to change the notification mechanism without modifying the core service logic.

This design follows the Dependency Inversion Principle, making the system more flexible, extensible, and maintainable. If you want to add a new notification method, you can simply create a new class implementing the INotificationChannel interface, and the NotificationService will work with it without any changes to its code.

public interface INotificationChannel
{
    void SendNotification(string message);
}

public class EmailService : INotificationChannel
{
    public void SendNotification(string message)
    {
        Console.WriteLine("Sending email: " + message);
    }
}

public class SMSService : INotificationChannel
{
    public void SendNotification(string message)
    {
        Console.WriteLine("Sending SMS: " + message);
    }
}

public class NotificationService
{
    private INotificationChannel _notificationChannel;

    public NotificationService(INotificationChannel notificationChannel)
    {
        _notificationChannel = notificationChannel;  // Depends on abstraction, not concrete class
    }

    public void SendNotification(string message)
    {
        _notificationChannel.SendNotification(message);
    }
}

In conclusion, following the SOLID design principles in .NET 9 leads to the development of clean, maintainable, and scalable systems. Each principle — whether it’s ensuring a class has a single responsibility, extending functionality without modification, substituting derived classes seamlessly, keeping interfaces focused, or decoupling components through abstractions — plays a crucial role in fostering high-quality software.

By applying these principles, developers can create systems that are easier to modify, extend, and test, ultimately resulting in more robust and flexible applications. In an ever-evolving software landscape, embracing SOLID ensures that your code remains adaptable and resilient to future changes.