A Deep Dive into Object-Oriented Design Principles with Real-World C# Examples

In software development, creating robust, maintainable, and scalable applications is essential. To achieve this, developers often rely on the SOLID principles, a set of five design principles that guide the creation of clean, modular, and extensible code. These principles are especially relevant in object-oriented design (OOD) and can help improve the overall structure of your application. In this article, we will explore each of the SOLID principles and provide real-world C# examples to demonstrate how they enhance software design.

S - Single Responsibility Principle (SRP)

The Single Responsibility Principle asserts that a class should have only one reason to change, meaning it should only have one job or responsibility. By adhering to SRP, you ensure that each class is focused on a single task, making the code more maintainable and easier to understand.

Example:

// Violation of SRP
public class UserManager
{
    public void AddUser(User user)
    {
        // Add user to database
        Database.Save(user);
    }

    public void SendWelcomeEmail(User user)
    {
        // Send email
        EmailService.SendEmail(user.Email, "Welcome!");
    }
}

// Adhering to SRP
public class UserManager
{
    private readonly EmailService _emailService;

    public UserManager(EmailService emailService)
    {
        _emailService = emailService;
    }

    public void AddUser(User user)
    {
        // Add user to database
        Database.Save(user);
    }
}

public class EmailService
{
    public void SendWelcomeEmail(User user)
    {
        // Send email
        SendEmail(user.Email, "Welcome!");
    }

    private void SendEmail(string email, string message)
    {
        // Email logic here
    }
}

In the first example, the UserManager class violates SRP by handling both user management and email functionality. In the refactored version, we extract the email logic into a separate EmailService class, adhering to SRP.

O - Open-Closed Principle (OCP)

The Open-Closed Principle states that software entities should be open for extension but closed for modification. This means that new functionality can be added without altering existing code, ensuring that the system remains stable while allowing for future enhancements.

Example:

// Violation of OCP
public class Shape
{
    public virtual double CalculateArea()
    {
        // Default implementation for rectangle
        return Width * Height;
    }

    public int Width { get; set; }
    public int Height { get; set; }
}

// Adhering to OCP
public abstract class Shape
{
    public abstract double CalculateArea();
}

public class Rectangle : Shape
{
    public override double CalculateArea()
    {
        return Width * Height;
    }

    public int Width { get; set; }
    public int Height { get; set; }
}

public class Circle : Shape
{
    public override double CalculateArea()
    {
        return Math.PI * Radius * Radius;
    }

    public int Radius { get; set; }
}

In the first example, adding a new shape requires modifying the Shape class. The second example adheres to the OCP by using inheritance, allowing new shapes to be added without modifying the base class, which makes the system more extensible.

L - Liskov Substitution Principle (LSP)

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. This ensures that derived classes maintain the behavior expected by the parent class.

Example:

// Violation of LSP
public class Bird
{
    public virtual void Fly()
    {
        // Basic flying logic
    }
}

public class Ostrich : Bird
{
    public override void Fly()
    {
        throw new NotImplementedException("Ostriches can't fly!");
    }
}

In this example, the Ostrich class violates LSP because it cannot fly, yet it inherits from Bird, which assumes that all birds can fly. A better approach would be to redesign the inheritance hierarchy:

// Adhering to LSP
public abstract class Bird
{
    public abstract void Move();
}

public class Sparrow : Bird
{
    public override void Move()
    {
        // Flying logic
    }
}

public class Ostrich : Bird
{
    public override void Move()
    {
        // Walking logic
    }
}

In the refactored example, we adhere to LSP by ensuring that subclasses do not violate expectations set by the parent class, offering more logical behavior.

I - Interface Segregation Principle (ISP)

The Interface Segregation Principle states that clients should not be forced to implement interfaces they do not use. Instead of having large, general-purpose interfaces, it’s better to have smaller, more specific ones that cater to the needs of different clients.

Example:

// Violation of ISP
public interface IWorker
{
    void Work();
    void Eat();
}

public class Worker : IWorker
{
    public void Work()
    {
        // Working logic
    }

    public void Eat()
    {
        // Eating logic
    }
}

public class Robot : IWorker
{
    public void Work()
    {
        // Working logic
    }

    public void Eat()
    {
        throw new NotImplementedException();
    }
}

In this example, the Robot class violates ISP by being forced to implement the Eat method, which it doesn’t need. A better approach would be:

// Adhering to ISP
public interface IWorkable
{
    void Work();
}

public interface IFeedable
{
    void Eat();
}

public class Worker : IWorkable, IFeedable
{
    public void Work()
    {
        // Working logic
    }

    public void Eat()
    {
        // Eating logic
    }
}

public class Robot : IWorkable
{
    public void Work()
    {
        // Working logic
    }
}

In this refactored version, the interfaces are segregated, and each class only implements the relevant interfaces, adhering to ISP.

D - Dependency Inversion Principle (DIP)

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules. Both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions. This principle promotes loose coupling between components.

Example:

// Violation of DIP
public class UserService
{
    private Database _database;

    public UserService()
    {
        _database = new Database(); // Hard dependency on Database
    }

    public void AddUser(User user)
    {
        _database.Save(user);
    }
}

public class Database
{
    public void Save(User user)
    {
        // Database logic
    }
}

In the above code, UserService is tightly coupled to the Database class. To adhere to DIP, we can invert the dependency:

// Adhering to DIP
public interface IDataRepository
{
    void Save(User user);
}

public class UserService
{
    private readonly IDataRepository _repository;

    public UserService(IDataRepository repository)
    {
        _repository = repository;
    }

    public void AddUser(User user)
    {
        _repository.Save(user);
    }
}

public class Database : IDataRepository
{
    public void Save(User user)
    {
        // Database logic
    }
}

In the refactored example, UserService no longer directly depends on the Database class but rather on the abstraction IDataRepository, making it more flexible and easier to test.

Conclusion

By following the SOLID principles, you create code that is modular, maintainable, and extensible. These principles, when applied correctly, help manage complexity and ensure that your codebase remains robust as it evolves. Whether you're working with C# or any other object-oriented language, adopting SOLID will elevate the quality of your software and make your applications easier to scale and maintain over time.