Composition Over Inheritance in C# Solution and Project Architecture

In software development, especially with C#, we often encounter two design principles: inheritance and composition. Both help us build flexible, maintainable code, but knowing when to use one over the other is key to creating robust applications. Enter the principle of Composition over Inheritance, an approach that advocates for structuring code to maximize modularity, testability, and adaptability.

In this post, we’ll explore how Composition over Inheritance applies to both solution architecture (how multiple projects interact) and project architecture (how classes and components within a single project are structured) in C#.

Why Composition Over Inheritance?

At a high level, composition means building functionality by combining simple, independent components rather than creating rigid, hierarchical structures. In contrast, inheritance is about creating a base (or parent) class that shares properties and methods with subclasses (or child classes).

While inheritance is powerful, it can lead to issues like:

1. Tight coupling: Changes to a base class can break child classes.
2. Limited flexibility: Extending complex class hierarchies makes code harder to refactor.
3. Reduced reusability: Classes become less reusable outside the hierarchy.

Composition solves these problems by allowing us to combine smaller, specialized components, increasing flexibility and making our code easier to test and extend. Let’s dive into how this applies at both the solution and project levels.

Solution Architecture: Composition vs. Inheritance

Solution architecture involves organizing multiple projects in a way that makes the system modular and maintainable. Here’s how Inheritance and Composition play out at this level:

Inheritance in Solution Architecture

With inheritance-like patterns in solution architecture, projects are organized in a hierarchical structure where projects depend on one another in layers.

Example:

• A solution with a Core project containing base classes and shared logic.
• A DataAccess project depends on Core for entities and base repositories.
• API or UI projects extend DataAccess, relying on it for database access and common logic.

While this structure works, it can lead to tight coupling. Changing Core classes can impact all dependent projects, creating a ripple effect. Over time, adding new features or reorganizing the solution can become difficult because of these interdependencies.

Composition in Solution Architecture

With composition, instead of a layered hierarchy, each project in the solution has a distinct role. Projects don’t inherit functionality from a central “base” project; they are designed to work independently, often communicating through shared, modular interfaces or libraries.

Example:

• Core: Holds only interfaces or simple data contracts (like DTOs).
• DataAccess: Implements interfaces for database interactions, independent of other projects.
• ServiceLayer: Contains business logic, only requiring the Core library interfaces.
• API or UI: Each project injects and composes the dependencies it needs, rather than depending on other projects for core functionality.

Benefits of Composition at the Solution Level:

• Modularity: Each project is independently responsible for its logic, increasing flexibility.
• Testability: Projects are easily isolated for unit tests.
• Scalability: New projects can be added without affecting others, and existing projects can evolve independently.

In Practice: In C#, this can be achieved with Dependency Injection (DI), where each project uses small, focused services that implement core interfaces. Each project can independently extend or replace these services as needed.

Project Architecture: Composition vs. Inheritance

Within a single project, inheritance and composition influence how classes and components interact. This level impacts how maintainable and testable individual features are, particularly as the project grows.

Inheritance in Project Architecture

In project architecture, inheritance is commonly seen in base classes. For example, in a C# Web API project, you might define a BaseController that other controllers inherit from, sharing functionality like logging, error handling, and authentication.

Example:

public class BaseController : Controller
{
    protected void LogAction(string action)
    {
        Console.WriteLine("Action logged: " + action);
    }
}

public class UserController : BaseController
{
    public IActionResult GetUser()
    {
        LogAction("GetUser called");
        return Ok("User data");
    }
}

Drawbacks:

• Limited flexibility: If UserController needs unique behaviour, it might have to override base methods or include unrelated base logic.
• Reduced reusability: Other classes that need logging but aren’t controllers can’t reuse LogAction, requiring redundant implementations elsewhere.

Composition in Project Architecture

In a composition-based project architecture, instead of creating a BaseController, we create small, single-responsibility services that can be injected and used as needed.

Example: Define an ILoggingService interface and implement it in LoggingService:

public interface ILoggingService
{
    void LogAction(string action);
}

public class LoggingService : ILoggingService
{
    public void LogAction(string action)
    {
        Console.WriteLine("Action logged: " + action);
    }
}

Then, inject LoggingService into any controller or class that needs logging:

public class UserController : Controller
{
    private readonly ILoggingService _loggingService;

    public UserController(ILoggingService loggingService)
    {
        _loggingService = loggingService;
    }

    public IActionResult GetUser()
    {
        _loggingService.LogAction("GetUser called");
        return Ok("User data");
    }
}

Benefits of Composition at the Project Level:

• Reusability: LoggingService can be used in any class, not just controllers.
• Flexibility: You can swap out LoggingService with a different implementation without changing the consuming classes.
• Testability: Classes depending on ILoggingService can be easily unit tested with a mock logging implementation.

Comparing Inheritance and Composition in Solution and Project Architecture

Here’s a summary comparing the impact of inheritance vs. composition across solution and project architectures:

Conclusion

In both solution and project architecture, favouring composition over inheritance leads to more flexible, maintainable, and testable code. By creating independent, focused components and services, we can achieve modular designs that are easier to manage and extend.

To implement this in C#, embrace Dependency Injection and design with interfaces and services. Whether at the solution or project level, composition enables you to build systems that are adaptable to change—perfect for maintaining a growing, complex application. Embracing composition doesn’t mean never using inheritance, but it’s a guiding principle to keep your code modular, reusable, and manageable.

Happy composing! 😊