Composition vs Inheritance in C#: When to Use Each

Inheritance says "I am a..." — Composition says "I have a..."

Imagine you're building a car. You could use inheritance: "A Car is a Vehicle" — that works. But a Car also has an engine, wheels, and a steering wheel. If you tried to model those with inheritance, you'd need a messy hierarchy: "Car is a Engine"? No, that's nonsense.

Inheritance is a powerful tool, but it's often overused. When you inherit, you tie your subclass tightly to the parent. That's fine for "is-a" relationships (like Dog is an Animal), but for "has-a" relationships (like a Car has an Engine), composition is the better choice.

In this lesson, you'll learn when to use inheritance, when to use composition, and why composition is often preferred in modern software design.

What Is It?

The Simple Explanation

Inheritance is the "is-a" relationship. A Dog is an Animal. A Square is a Shape. The subclass inherits behavior from the base class.

Composition is the "has-a" relationship. A Car has an Engine. A House has a Door. The class contains instances of other classes to provide functionality.

The Technical Definition

Inheritance (in OOP) is a mechanism where a class derives from another class, gaining its members and behavior. In C#, inheritance is single (a class can inherit from only one base class) but allows method overriding and polymorphism.

Composition is a design principle where a class contains objects of other classes as fields or properties. It delegates work to those contained objects, effectively "composing" behavior from multiple parts.

Why Does It Exist?

The Problem with Overusing Inheritance

Inheritance sounds great — "reuse code!" — but it comes with hidden costs:

• Fragile Base Class — changes to the base class can break all subclasses, even if you didn't touch them.
• Inflexibility — once you inherit, you're stuck with the parent's behavior unless you override it (which can be complex).
• Deep Hierarchies — they become hard to understand and maintain.
• Cannot change at runtime — the relationship is fixed at compile time.
• Inheritance is limited to one base class in C#, so you can't combine multiple behaviors.

The Solution — Prefer Composition

Composition solves these issues:

• Loose coupling — components are independent and can be changed without affecting each other.
• Flexibility — you can swap parts at runtime (e.g., change the engine of a car).
• Reusability — you can compose behavior from many different objects.
• No deep hierarchies — your classes remain flat and simple.
• Easier testing — you can mock the parts.

The principle "Favor composition over inheritance" is one of the most important design guidelines in object-oriented programming.

Big Picture

How It Works

public class Animal
{
    public virtual void Speak() => Console.WriteLine("...");
}

public class Dog : Animal
{
    public override void Speak() => Console.WriteLine("Woof!");
}

Animal animal = new Dog();
animal.Speak(); // "Woof!"

public class Engine
{
    public void Start() => Console.WriteLine("Engine started");
}

public class Car
{
    private Engine _engine = new Engine();
    public void Start() => _engine.Start();
}

Simple Example

Inheritance — "is-a"

public class Shape
{
    public virtual double Area() => 0;
}
public class Rectangle : Shape
{
    public double Width { get; set; }
    public double Height { get; set; }
    public override double Area() => Width * Height;
}
public class Circle : Shape
{
    public double Radius { get; set; }
    public override double Area() => Math.PI * Radius * Radius;
}

Meaning: A Rectangle is a Shape. Circle is a Shape. They share a common base and can be used polymorphically.

Composition — "has-a"

public class Logger
{
    public void Log(string message) => Console.WriteLine($"Log: {message}");
}
public class OrderService
{
    private Logger _logger; // composition
    public OrderService(Logger logger) => _logger = logger;
    public void ProcessOrder() => _logger.Log("Order processed");
}

Meaning: OrderService has a Logger. It doesn't inherit from Logger; it uses it. This makes OrderService flexible — you can swap loggers or mock them for testing.

Real-World Example

Consider a notification system that can send emails, SMS, and push notifications. With inheritance, you might create a base Notifier and derive EmailNotifier, SmsNotifier, etc. But if you need to combine behaviors (e.g., email + SMS), inheritance fails.

With composition, you can create small, focused classes and combine them flexibly.

// ─── Parts (composition) ───
public interface IMessageSender
{
    void Send(string message);
}

public class EmailSender : IMessageSender
{
    public void Send(string message) => Console.WriteLine($"Email: {message}");
}

public class SmsSender : IMessageSender
{
    public void Send(string message) => Console.WriteLine($"SMS: {message}");
}

public class PushSender : IMessageSender
{
    public void Send(string message) => Console.WriteLine($"Push: {message}");
}

// ─── Composed Notification Service ───
public class NotificationService
{
    private readonly List<IMessageSender> _senders;

    public NotificationService(params IMessageSender[] senders)
    {
        _senders = senders.ToList();
    }

    public void Notify(string message)
    {
        foreach (var sender in _senders)
            sender.Send(message);
    }
}

// ─── Usage ───
var service = new NotificationService(
    new EmailSender(),
    new SmsSender()
);
service.Notify("Order shipped!"); // Sends both email and SMS

Why this is better than inheritance:

• You can compose any combination of senders at runtime.
• Adding a new sender (e.g., SlackSender) doesn't require changing existing code.
• Each sender is focused and testable in isolation.
• No deep inheritance hierarchies — just interfaces and composition.

Analogy

Under the Hood

Common Confusion

1. "Composition is just using objects" — yes, but it's a design principle

Every class that uses another object is using composition. The principle is about preferring composition over inheritance when designing relationships. It's not just a tactic; it's a mindset to favor loose coupling.

2. "Inheritance is always bad" — no, it has its place

Inheritance is great for genuine "is-a" relationships where the behavior is truly shared and unlikely to change. For example, a List<T> inherits from Collection<T> because a list is a collection. Use inheritance when the relationship is stable and you want to reuse code and enable polymorphism.

3. "Composition is always more code" — yes, but it's worth it

Composition often requires writing more code (delegating methods), but the code is simpler, more testable, and more maintainable. The extra lines are a small price for flexibility.

Common Mistakes

Mistake 1 — Forcing inheritance for convenience

Creating a base class just to share a few helper methods, even when there's no logical "is-a" relationship.

public class UtilityBase
{
    public void Log(string msg) { ... }
}
public class OrderService : UtilityBase { } // Not an "is-a"

Use composition: inject a logger instead.

Mistake 2 — Over-engineering with composition

Composing everything into tiny pieces, making the design overly complex for simple problems.

Use the right tool for the job. For trivial cases, a simple inheritance might be fine.

Mistake 3 — Not using interfaces with composition

Hard-coding concrete components inside a class, making it hard to swap or test.

public class OrderService
{
    private Logger _logger = new Logger(); // tight coupling
}

Depend on an interface: private readonly ILogger _logger; and inject it.

When Should I Use It?

Use inheritance when:

• There is a clear, stable "is-a" relationship.
• You want to reuse code and override behavior.
• You need runtime polymorphism (virtual dispatch).
• The relationship is unlikely to change.
• You are designing a framework where base classes provide default behavior.

Use composition when:

• There is a "has-a" relationship (which is most of the time).
• You need flexibility to change behavior at runtime.
• You want to keep classes small and focused.
• You want to enable unit testing with mocks.
• You need to combine behavior from multiple sources (multiple inheritance of behavior).

Mental Model

Key Takeaway

Check Your Understanding

You've learned the difference between inheritance and composition, and when to use each. Let's see if you can apply these concepts.

You now understand the trade-offs between inheritance and composition — you can design more flexible, maintainable systems!