You know "has-a." Now let's see composition as the actual load-bearing structure of every flexible, testable service you'll build.

In Foundations you saw composition as the polite alternative to inheritance — "a Car has an Engine." That's true, but it undersells what composition actually does in a real system. Watch what happens when a requirement changes on a composed design versus an inherited one:

// Requirement: "Orders over $10,000 need fraud review before discounting."
// With composition, this is a five-minute change: swap in a different strategy.
var pricer = new OrderPricer(
    discountStrategy: order.Total > 10_000
        ? new FraudReviewDiscountStrategy(new PercentageDiscountStrategy(0.1m))
        : new PercentageDiscountStrategy(0.1m));

// With inheritance, the same requirement usually means either:
//   1. a new subclass combination for every case that now needs fraud review, or
//   2. an if-check jammed into the base class that every subclass now carries around.
// Composition let the requirement become a runtime decision about which PARTS to plug in.

This is the real payoff of composition: it turns "which behavior does this object have" from a compile-time, hierarchy-shaped decision into a runtime, plug-in-shaped decision. That single shift is what makes composed systems easy to extend without touching existing, tested code.

In this lesson, you'll see composition as it's actually used in production: composing behavior by injecting interfaces, the Strategy-pattern shape that composition naturally takes, building flexible services from small composed parts, and how this sets up the Dependency Inversion Principle covered in the capstone lesson (081).

Composition, in Practice

You already know composition means holding a reference to another object and delegating to it. In real applications, the object you hold a reference to is almost always an interface, not a concrete class — that one detail is what unlocks everything else in this lesson.

This is composition wired to an interface instead of a class — and it's exactly the shape of the classic Strategy pattern: a class holds a reference to an interchangeable "strategy" object and delegates a specific piece of behavior to it, without knowing or caring which concrete strategy it actually received.

Why Composition Is the Backbone of Flexible Design

Every real application eventually needs to vary behavior along an axis that isn't known at the time the "container" class was written: different pricing rules per market, different notification channels per user preference, different export formats per customer request. If that variation is modeled with inheritance, you get a new subclass — or worse, a combinatorial explosion of subclasses — for every new combination. If it's modeled with composition, you get a new small class implementing an existing interface, plugged into a container that never has to change.

This is the mechanical reason "favor composition over inheritance" works in practice: composition lets you add behavior by adding a new, isolated class, instead of editing an existing, shared one. That's the Open/Closed Principle in action — open for extension (add a new strategy), closed for modification (the container class never changes).

Big Picture — Composing a Service from Small Parts

Every axis of variation — where the data comes from, what format it's exported to, how completion is announced — is a separate, independently swappable interface. Adding "export to PDF" never touches ReportEngine, IReportDataSource, or any existing exporter.

Simple Example — The Strategy Shape

public interface IDiscountStrategy
{
    decimal Apply(decimal originalPrice);
}

public sealed class NoDiscount : IDiscountStrategy
{
    public decimal Apply(decimal originalPrice) => originalPrice;
}

public sealed class PercentageDiscount(decimal percent) : IDiscountStrategy
{
    public decimal Apply(decimal originalPrice) => originalPrice * (1 - percent);
}

public sealed class FixedAmountDiscount(decimal amount) : IDiscountStrategy
{
    public decimal Apply(decimal originalPrice) => Math.Max(0, originalPrice - amount);
}

// The container — composed with a strategy, doesn't know or care which one
public sealed class OrderPricer(IDiscountStrategy discountStrategy)
{
    public decimal GetFinalPrice(decimal originalPrice) => discountStrategy.Apply(originalPrice);
}

// Usage — the SAME OrderPricer class handles every case
var regular = new OrderPricer(new NoDiscount());
var sale = new OrderPricer(new PercentageDiscount(0.20m));
var clearance = new OrderPricer(new FixedAmountDiscount(15m));

Console.WriteLine(sale.GetFinalPrice(100m));   // 80

Code → Meaning → Result: OrderPricer is composed with whatever IDiscountStrategy it's given at construction — a primary constructor parameter, captured as a field automatically. Adding a new discount rule (a holiday discount, a loyalty discount) never means touching OrderPricer; it means writing one new class that implements IDiscountStrategy.

Real-World Example — A Notification Service Composed of Interchangeable Channels

A notification system needs to send messages through different channels, sometimes several at once, and the set of channels needs to grow without anyone touching the core service.

public interface INotificationChannel
{
    string ChannelName { get; }
    Task SendAsync(string recipient, string message, CancellationToken ct = default);
}

public sealed class EmailChannel(ISmtpClient smtp) : INotificationChannel
{
    public string ChannelName => "Email";

    public async Task SendAsync(string recipient, string message, CancellationToken ct = default)
    {
        await smtp.SendAsync(recipient, "Notification", message, ct);
    }
}

public sealed class SmsChannel(ISmsGateway gateway) : INotificationChannel
{
    public string ChannelName => "SMS";

    public async Task SendAsync(string recipient, string message, CancellationToken ct = default)
    {
        await gateway.SendTextAsync(recipient, message, ct);
    }
}

// The container class — composed with a COLLECTION of channels, not one hard-coded channel
public sealed class NotificationService(IEnumerable<INotificationChannel> channels)
{
    public async Task NotifyAsync(string recipient, string message, CancellationToken ct = default)
    {
        var tasks = channels.Select(channel => SendSafelyAsync(channel, recipient, message, ct));
        await Task.WhenAll(tasks);
    }

    private static async Task SendSafelyAsync(
        INotificationChannel channel, string recipient, string message, CancellationToken ct)
    {
        try
        {
            await channel.SendAsync(recipient, message, ct);
        }
        catch (Exception ex)
        {
            Console.WriteLine($"[{channel.ChannelName}] failed: {ex.Message}");
        }
    }
}

// Usage — composed at startup, e.g. via dependency injection (lesson 081)
var service = new NotificationService(
[
    new EmailChannel(smtpClient),
    new SmsChannel(smsGateway)
]);

await service.NotifyAsync("user@example.com", "Your order has shipped!");

Why this holds up as requirements change:

• Adding a PushNotificationChannel or a SlackChannel next quarter means writing one new class — NotificationService never changes.
• A single channel failing (say, the SMS gateway is down) doesn't take down the others — each is isolated, tested, and reasoned about independently.
• Unit testing NotificationService requires only fake INotificationChannel implementations — no real SMTP server or SMS gateway needed.
• Which channels are active for a given user can be a runtime decision (read from user preferences), something inheritance simply cannot express.

Analogy

Under the Hood

Common Confusion

Composition vs. the Strategy pattern — are they the same thing?

Composition is the general mechanism (a class holds and delegates to another object). Strategy is a specific, named use of composition: composing with an interface specifically to make one algorithm or behavior swappable at will. Every Strategy-pattern implementation uses composition; not every use of composition is "the Strategy pattern" (a Car holding an Engine is composition, but there's usually only ever one kind of engine in play at a time — no interchangeable strategy in the classic sense).

"Composing with interfaces" vs. Dependency Inversion — related, not identical

Composing a class with an interface field is the mechanism. Dependency Inversion (lesson 081) is the principle that says high-level modules (like NotificationService) should depend on abstractions (INotificationChannel) rather than concrete low-level details (EmailChannel). Everything in this lesson is already following that principle — you'll see it named and formalized in the capstone.

Common Mistakes

Mistake 1 — Composing with a concrete type instead of an abstraction

public sealed class OrderPricer
{
    private readonly PercentageDiscount _discount = new(0.1m); //  locked to one concrete strategy
}

Depend on the interface (IDiscountStrategy) and receive the concrete implementation from outside — you get all the flexibility of composition only when the field type is the abstraction, not the implementation.

Mistake 2 — Over-fragmenting into interfaces with a single, never-changing implementation

Wrapping every helper method behind its own interface "just in case," even when there's exactly one implementation and no realistic scenario for a second one. This adds indirection and files without buying any real flexibility.

Introduce an interface when there's a genuine reason to swap implementations (production vs. test, multiple real variants, or a team boundary) — not reflexively for every class.

Mistake 3 — Letting the container class know too much about its parts

public async Task NotifyAsync(string recipient, string message)
{
    foreach (var channel in channels)
    {
        //  NotificationService now knows about specific channel TYPES —
        // defeats the purpose of composing against an interface
        if (channel is SmsChannel sms && !IsValidPhoneNumber(recipient))
            continue;
        await channel.SendAsync(recipient, message);
    }
}

Push channel-specific logic (like validating a phone number) inside the channel's own implementation of SendAsync, not into the container that's supposed to treat every channel uniformly.

When Should I Use It?

• You expect a behavior to vary — now or later — along an axis the class shouldn't need to know the full set of options for (payment methods, export formats, notification channels, pricing rules).
• You need the class to be unit-testable in isolation, without spinning up real infrastructure (a database, an SMTP server, a payment gateway).
• Multiple, genuinely independent axes of variation exist in the same domain (channel type and retry policy and formatting) — composition lets each axis be a separate, independently swappable interface, instead of forcing a combinatorial class explosion.

Mental Model

Key Takeaway

Check Your Understanding

Let's confirm you can recognize composition-based design and know why it's structured this way.

You can now recognize the Strategy shape everywhere — and you're set up perfectly for polymorphism (074), which explains exactly how that runtime dispatch through an interface actually works.

dotnetmadeeasy.com — Learn C# and .NET, the right way.