One class, several capabilities. This is where interfaces stop looking like inheritance and start looking like what they actually are.

A single class in a real system is rarely "just one thing." An Order entity might need to be auditable (someone needs to know who changed it and when), cacheable (it's read far more often than it's written), and comparable (you need to sort a list of them by priority). None of these are the same relationship, and none of them should force Order into somebody else's inheritance chain:

public sealed class Order : IAuditable, ICacheable, IComparable<Order>
{
    public Guid Id { get; }
    public DateTime CreatedAtUtc { get; }
    public DateTime? ModifiedAtUtc { get; private set; }
    public int Priority { get; }

    // Satisfies IAuditable
    public void RecordModification() => ModifiedAtUtc = DateTime.UtcNow;

    // Satisfies ICacheable
    public string CacheKey => $"order:{Id}";
    public TimeSpan CacheDuration => TimeSpan.FromMinutes(5);

    // Satisfies IComparable<Order>
    public int CompareTo(Order? other) => Priority.CompareTo(other?.Priority ?? 0);
}
// Order extends NOTHING and implements THREE interfaces — each one an
// independent, focused capability, none of which know the others exist.

This is the payoff of composing capabilities through interfaces instead of a single tangled base class: each capability is small, independently understandable, and completely decoupled from the others. Adding a fourth capability later never requires touching the first three.

In this lesson, you'll learn how to implement several interfaces on one class cleanly, how C# resolves — or refuses to silently resolve — naming conflicts between interfaces, and how to think about class design as composing capabilities rather than inheriting identity.

What Is It?

A C# class can implement any number of interfaces, separated by commas after the base class (if any). Unlike class inheritance, there's no "one slot" limit — the compiler simply requires that the class provide an implementation for every member of every interface it lists.

public class ExpressCarrierProcessor : ShipmentProcessor, IAuditable, ICacheable
//                                       ^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^  ^^^^^^^^^^
//                                       one base class      any number of interfaces

You already saw this shape informally in lesson 073's NotificationService, where each channel implemented a single interface. This lesson is about what happens once a class needs to satisfy several interfaces at once — and what to do when two of them disagree.

Why This Matters — Composing Capabilities, Not Inheriting Identity

If C# only allowed single inheritance and no interfaces, modeling "a thing that is auditable, cacheable, and comparable" would force an impossible choice: pick one base class to inherit the logic from, and hand-roll the rest. Multiple interface implementation removes that constraint entirely — a class's set of capabilities is just a list, and that list can grow to fit reality instead of being squeezed to fit a single hierarchy.

This is the direct, practical payoff of the "is-a" vs. "can-do" distinction from lesson 077: Order is not an Auditable, it's not a Cacheable — it can be audited, it can be cached. Modeling capabilities as interfaces keeps the language matching the actual relationship.

Big Picture

Each caller depends on exactly the capability it needs and nothing more. This narrow, targeted dependency shape is exactly what lesson 079 will formalize as the Interface Segregation Principle — small, focused interfaces, freely combined.

Resolving Naming Conflicts Between Interfaces

Two interfaces can declare a member with the exact same name and signature. C# does not treat this as an error by default — it treats it as one shared obligation, which a single implementation can satisfy for both:

public interface IPrintable { void Render(); }
public interface IExportable { void Render(); }   // same signature, different intent

public sealed class Document : IPrintable, IExportable
{
    // ONE method satisfies BOTH interfaces — because the signatures match exactly
    public void Render() => Console.WriteLine("Rendering document...");
}

This works cleanly when both interfaces genuinely mean the same thing by Render(). The real problem shows up when they don't — when IPrintable.Render() is supposed to produce a physical print job, and IExportable.Render() is supposed to produce a byte array, but both happen to share the name Render. A single implicit method can't honor two different meanings at once. That's exactly the case explicit interface implementation (lesson 080) exists to solve — giving each interface its own separate implementation on the same class, even when the member names collide:

public sealed class Document : IPrintable, IExportable
{
    void IPrintable.Render() => SendToPrinter();          // one meaning
    byte[] IExportable.Render() => SerializeToBytes();    // a different meaning, different return type

    // Note: overload resolution alone can't disambiguate same-name, same-parameter
    // members with DIFFERENT return types either — explicit implementation is
    // the actual mechanism, covered fully in lesson 080.
}

Simple Example

public interface IDisposableResource
{
    void Release();
}

public interface IHealthCheckable
{
    bool IsHealthy();
}

public sealed class DatabaseConnection : IDisposableResource, IHealthCheckable
{
    private bool _open = true;

    public void Release()
    {
        _open = false;
        Console.WriteLine("Connection released.");
    }

    public bool IsHealthy() => _open;
}

// Callers depend on exactly the capability they need
void Cleanup(IDisposableResource resource) => resource.Release();
void Monitor(IHealthCheckable checkable) => Console.WriteLine(checkable.IsHealthy());

var db = new DatabaseConnection();
Monitor(db);    // True
Cleanup(db);    // "Connection released."
Monitor(db);    // False — same object, viewed through a different capability

Code → Meaning → Result: DatabaseConnection is one object with two independent capabilities. Cleanup and Monitor each see only the slice of it they actually need — neither function needs to know DatabaseConnection exists as a concrete type at all.

Real-World Example — A Notification Plugin Implementing Several Capabilities

Extending lesson 073's notification system: a Slack channel plugin needs to be a working INotificationChannel, but it also needs to expose configuration validation and startup health checks — capabilities the plugin host system requires from any plugin, not just notification channels.

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

public interface IConfigurable
{
    IReadOnlyList<string> ValidateConfiguration();
}

public interface IStartupHealthCheckable
{
    Task<bool> CheckHealthAsync(CancellationToken ct = default);
}

public sealed class SlackChannel(SlackChannelOptions options, ISlackClient client)
    : INotificationChannel, IConfigurable, IStartupHealthCheckable
{
    public string ChannelName => "Slack";

    public async Task SendAsync(string recipient, string message, CancellationToken ct = default) =>
        await client.PostMessageAsync(options.WebhookUrl, recipient, message, ct);

    public IReadOnlyList<string> ValidateConfiguration()
    {
        var errors = new List<string>();
        if (string.IsNullOrWhiteSpace(options.WebhookUrl))
            errors.Add("Slack webhook URL is required.");
        return errors;
    }

    public async Task<bool> CheckHealthAsync(CancellationToken ct = default) =>
        await client.PingAsync(options.WebhookUrl, ct);
}

// The plugin host only ever asks for the capability it needs at that moment:
foreach (var plugin in loadedPlugins.OfType<IConfigurable>())
{
    var errors = plugin.ValidateConfiguration();
    if (errors.Count > 0)
        throw new InvalidOperationException($"Plugin misconfigured: {string.Join("; ", errors)}");
}

foreach (var channel in loadedPlugins.OfType<INotificationChannel>())
    await channel.SendAsync("ops-team", "Deployment complete.");

Why this design holds up in a real plugin host:

• SlackChannel doesn't need to inherit from some generic PluginBase just to gain configuration validation — it implements IConfigurable directly, alongside its other capabilities.
• A future plugin that has no meaningful health check simply doesn't implement IStartupHealthCheckable — loadedPlugins.OfType<IStartupHealthCheckable>() naturally filters it out, with no special-casing required anywhere.
• The host system's code (the two foreach loops) never needs to know the concrete plugin types at all — it discovers capabilities purely through interface checks, using C#'s OfType<T>() as a natural capability filter.

Under the Hood

Common Confusion

"Implementing many interfaces" vs. "a fat interface" — not the same thing

A class implementing five small, focused interfaces (IAuditable, ICacheable, IComparable<T>...) is a healthy, common design. A class implementing one interface with thirty members, most of which it doesn't really need, is the opposite problem — a single "fat" contract forced onto every implementer. Lesson 079 covers exactly this distinction and why the second shape hurts.

Same signature ≠ automatically a conflict

Two interfaces sharing a member with the exact same name, parameters, and return type are not in conflict at all — a single method on the implementing class satisfies both, as shown with Render() above. A real conflict only exists when the interfaces expect genuinely different behavior or return types under the same name — that's the narrower case explicit interface implementation exists for.

Common Mistakes

Mistake 1 — Implementing an interface member with unrelated behavior, just because the name matches

public interface IPrintable { void Render(); }      // means: send to a physical printer
public interface IExportable { void Render(); }      // means: write to disk as a file

public sealed class ReportDocument : IPrintable, IExportable
{
    //  ONE Render() now has to somehow mean BOTH "print this" and "export this" —
    // it can't honestly satisfy both intents with one implementation
    public void Render() => Console.WriteLine("Doing... something?");
}

When two interfaces share a name but mean genuinely different things, use explicit interface implementation (lesson 080) to give each its own separate, correct implementation — never force one method body to serve two different contracts by accident.

Mistake 2 — Implementing an interface a class doesn't genuinely support, just to satisfy a type check

Adding IStartupHealthCheckable to a plugin and having CheckHealthAsync always return true with no real check, purely so the plugin "shows up" somewhere it's expected — this is dishonest about the class's actual capabilities and defeats the purpose of the interface entirely.

Only implement an interface when the class genuinely provides that capability. If a plugin has no meaningful health check, it should not implement IStartupHealthCheckable at all — letting OfType<T>() correctly exclude it, as shown in the real-world example.

Mistake 3 — Piling every possible capability onto one interface instead of splitting them

Defining a single IPlugin interface with fifteen members covering configuration, health checks, notification sending, logging, and more — forcing every plugin to implement all fifteen, even the ones that make no sense for it.

Split by genuine capability, as shown in the real-world example — INotificationChannel, IConfigurable, IStartupHealthCheckable — and let each plugin implement exactly the subset it actually supports. This is the core idea lesson 079 names and formalizes.

When Should I Use It?

• A class genuinely has several independent capabilities, and forcing them into one interface or one inheritance chain would misrepresent the actual relationships.
• Different callers only need to know about a subset of what a class can do — modeling those subsets as separate interfaces lets each caller depend on exactly what it uses.
• You're building a plugin or extension system where not every implementer supports every capability, and you need a clean, type-safe way to discover which ones do.

Mental Model

Key Takeaway

Check Your Understanding

Let's confirm you can reason about composing capabilities through multiple interfaces.

You now think of class design as composing capabilities — which sets up interface segregation (079) as the natural next question: how small should each of those interfaces actually be?

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