The precision tool for when two interfaces genuinely disagree — and for keeping a class's public face honest about what it's really for.

Lesson 078 left you with a promise it deferred: two interfaces that share a member name but mean genuinely different things can't both be satisfied by one ordinary method body. Here's that exact situation, forced to a head:

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() has to somehow mean both "print this" and "export this."
    // It physically cannot honor two different intents under one name and one body.
    public void Render() => Console.WriteLine("Doing... something?");
}

The compiler doesn't complain about this — the code above compiles just fine and silently does the wrong thing for whichever caller didn't get the behavior it expected. That's the actual danger: a naming collision like this doesn't fail loudly, it fails quietly, in whichever direction the one shared method body happened to be written.

In this lesson, you'll learn explicit interface implementation — the void IInterface.Method() syntax — why it exists to resolve exactly this kind of collision, how it lets a class hide an implementation detail from its own public surface, and the specific situations where it's the right tool versus where it's overkill.

What Is Explicit Interface Implementation?

Every interface member you've implemented so far has been implicit: you write a normal public method or property, and the compiler quietly connects it to the matching interface member. Explicit interface implementation is a different syntax — you prefix the member with the interface's name, drop the access modifier entirely, and the resulting member is only reachable through a reference typed as that interface:

public sealed class ReportDocument : IPrintable, IExportable
{
    void IPrintable.Render() => SendToPrinter();      // explicit — no "public", prefixed with IPrintable.
    void IExportable.Render() => WriteExportFile();    // explicit — a completely separate implementation

    private void SendToPrinter() => Console.WriteLine("Sending to physical printer...");
    private void WriteExportFile() => Console.WriteLine("Writing export file to disk...");
}

var doc = new ReportDocument();
// doc.Render();                 //  Does not compile — Render() is not on ReportDocument's public surface at all
((IPrintable)doc).Render();      //  "Sending to physical printer..."
((IExportable)doc).Render();     //  "Writing export file to disk..."

IPrintable printable = doc;
printable.Render();              //  Same call, no cast needed — the variable's static type is already IPrintable

Two things changed compared to lesson 078's shared-signature case. First, each interface now gets its own method body — the naming collision is resolved because the compiler knows exactly which Render() you mean from the reference type doing the calling. Second, neither Render() shows up when you call a member directly on a ReportDocument-typed variable — explicit members are invisible on the class's own public surface, reachable only through the interface.

Why Does It Exist?

Explicit interface implementation solves two distinct problems, and it's worth keeping them separate in your head because they lead to different design decisions:

• Problem 1 — Genuine name collisions. Two interfaces declare a member with the same name and signature, but different intended behavior. Without explicit implementation, there is no way for one class to satisfy both honestly — one implicit method body can't mean two different things at once. This is the IPrintable/IExportable case above.
• Problem 2 — Hiding an implementation detail from the class's own public surface. Sometimes a class has to implement an interface member for a specific, narrow reason — satisfying a framework contract, participating in a pattern like IComparable<T> or IDisposable — but that member isn't really part of how the class wants to present itself day-to-day. Explicit implementation lets the member exist (satisfying the contract) without cluttering the class's ordinary public API.

Both problems come from the same root cause: an interface member is a promise to a specific caller, not necessarily a promise the implementing class wants to advertise to everyone. Explicit implementation is the mechanism that lets those two audiences — "code that holds an IPrintable" versus "code that holds a ReportDocument" — see different things.

Big Picture — Two Faces, One Object

This is not two objects and not two copies of any state — it's one object in memory, with the compiler restricting which door you're allowed to knock on depending on the static type of the reference you're holding.

The Syntax, Step by Step

void IPrintable.Render() { ... }
// No "public" — explicit members can never carry an access modifier

void IPrintable.Render() { ... }
//   ^^^^^^^^^^^ this qualifier is what makes it "explicit" and disambiguates it

((IPrintable)doc).Render();     // via cast
IPrintable p = doc; p.Render(); // via a variable already typed as the interface

Simple Example

public interface IBox { int Volume { get; } }
public interface IContainer { int Volume { get; } }   // same shape, different intended meaning

public sealed class ShippingCrate : IBox, IContainer
{
    private readonly int _lengthCm;
    private readonly int _widthCm;
    private readonly int _heightCm;
    private readonly int _maxPayloadCm3;

    public ShippingCrate(int lengthCm, int widthCm, int heightCm, int maxPayloadCm3)
    {
        _lengthCm = lengthCm;
        _widthCm = widthCm;
        _heightCm = heightCm;
        _maxPayloadCm3 = maxPayloadCm3;
    }

    // IBox.Volume = the crate's own physical size
    int IBox.Volume => _lengthCm * _widthCm * _heightCm;

    // IContainer.Volume = how much cargo it can actually hold (less than physical size, due to padding)
    int IContainer.Volume => _maxPayloadCm3;
}

var crate = new ShippingCrate(lengthCm: 50, widthCm: 40, heightCm: 30, maxPayloadCm3: 52_000);
Console.WriteLine(((IBox)crate).Volume);         // 60000 — physical dimensions
Console.WriteLine(((IContainer)crate).Volume);   // 52000 — usable payload capacity

Code → Meaning → Result: Both interfaces genuinely mean "volume," but they mean different kinds of volume for the same physical object. Explicit implementation lets ShippingCrate report an honest, different number for each meaning, instead of picking one and quietly lying to whichever caller wanted the other.

Real-World Example — A Payment Gateway Adapter with a Hidden Legacy Contract

A payment processing service exposes a clean, modern IPaymentGateway to the rest of the application. But the concrete Stripe adapter also has to satisfy a legacy ILegacyChargeable interface that an old batch-reconciliation job still depends on — a contract the team wants working, but never wants a new developer to stumble onto while exploring the class in an IDE.

public interface IPaymentGateway
{
    Task<PaymentResult> ChargeAsync(decimal amount, string currency, string customerToken, CancellationToken ct = default);
    Task<PaymentResult> RefundAsync(string transactionId, decimal amount, CancellationToken ct = default);
}

// A legacy interface the nightly reconciliation batch job still requires —
// its shape predates async/await and doesn't match the modern gateway's style at all
public interface ILegacyChargeable
{
    int Charge(string accountRef, int amountCents);   // synchronous, cents-based, no currency
}

public sealed class StripePaymentGateway(IStripeClient client) : IPaymentGateway, ILegacyChargeable
{
    // The gateway's real, everyday public API — this is what 99% of the application uses
    public async Task<PaymentResult> ChargeAsync(
        decimal amount, string currency, string customerToken, CancellationToken ct = default)
    {
        var response = await client.CreateChargeAsync(amount, currency, customerToken, ct);
        return response.Succeeded
            ? PaymentResult.Success(response.TransactionId)
            : PaymentResult.Failed(response.DeclineReason);
    }

    public async Task<PaymentResult> RefundAsync(
        string transactionId, decimal amount, CancellationToken ct = default)
    {
        var response = await client.CreateRefundAsync(transactionId, amount, ct);
        return response.Succeeded
            ? PaymentResult.Success(response.TransactionId)
            : PaymentResult.Failed(response.DeclineReason);
    }

    // Explicit — satisfies the legacy batch job's contract without ever showing up
    // on IntelliSense for "stripeGateway.", and without polluting the modern API's shape.
    // It's a thin, blocking adapter over the real async method — isolated here, not spread everywhere.
    int ILegacyChargeable.Charge(string accountRef, int amountCents)
    {
        var result = ChargeAsync(amountCents / 100m, "USD", accountRef)
            .GetAwaiter().GetResult();   // acceptable ONLY inside this narrow legacy-adapter seam
        return result.Success ? 1 : 0;
    }
}

// Everyday application code sees only the clean, modern surface:
IPaymentGateway gateway = new StripePaymentGateway(stripeClient);
await gateway.ChargeAsync(49.99m, "USD", customerToken, ct);
// gateway.Charge(...)   doesn't exist here — ILegacyChargeable is invisible through IPaymentGateway

// Only the old batch job, which still genuinely needs it, reaches the legacy member:
ILegacyChargeable legacy = new StripePaymentGateway(stripeClient);
legacy.Charge(accountRef: "acct_123", amountCents: 4999);

Why this design holds up in a real codebase:

• A developer typing stripeGateway. in their editor sees ChargeAsync and RefundAsync — the modern, correct API — and never sees the synchronous, cents-based Charge method that exists purely for one old batch job's sake.
• StripePaymentGateway still genuinely satisfies ILegacyChargeable — the compiler enforces it, the batch job keeps working, and nobody had to duplicate the charging logic or maintain two divergent code paths.
• The blocking GetAwaiter().GetResult() call — normally a red flag in async code — is contained to exactly one narrow, clearly-labeled adapter seam instead of being a pattern someone might copy elsewhere in the codebase after seeing it "just sitting there" as a public method.
• When the legacy batch job is eventually retired, deleting ILegacyChargeable and its one explicit implementation is a clean, contained removal — it never got tangled into StripePaymentGateway's primary API surface.

Analogy — The Badge That Opens Different Doors

Think of the object as a building, and each interface reference as a different badge someone is holding. The IPrintable badge opens the "send to printer" door. The IExportable badge opens a completely different "write to disk" door — even though, confusingly, both doors happen to be labeled "Render." Someone standing at the building's main public entrance, holding no special badge at all, doesn't see either door — because Render was never part of the building's main lobby directory. The badge you're holding determines which door you can even find, let alone open — and that's exactly what the static type of your reference variable does with explicit interface members.

Under the Hood

Common Confusion

Explicit implementation is not a privacy modifier

It's tempting to think of explicit implementation as "a way to make a method private-ish." It isn't — the member is still fully public, callable by any code that has an interface-typed reference to the object. Nothing stops a caller from writing ((IPrintable)doc).Render(). What explicit implementation controls is discoverability through the concrete class, not actual access — it is a design signal ("this isn't part of this class's everyday identity"), not a security boundary.

"Same signature" doesn't automatically mean you need this — see lesson 078 first

Lesson 078 already showed that two interfaces sharing an identical signature and meaning merge cleanly into one implicit method — no explicit implementation required. Reach for explicit implementation only when the meanings genuinely diverge, as with IBox.Volume versus IContainer.Volume above. Using it reflexively for every shared name, even when one implementation would honestly satisfy both, adds indirection with no real benefit.

Common Mistakes

Mistake 1 — Reaching for explicit implementation as a general-purpose "hide this method" tool

Making a method explicit purely because a developer doesn't want it cluttering IntelliSense, when there's no genuine naming collision and no real "this belongs to a different audience" reason — the member just becomes harder to find for no real design benefit, and callers have to know a specific cast or interface-typed variable exists to use it at all.

Reserve explicit implementation for genuine collisions (Problem 1) or a deliberate decision that a member is not part of the class's everyday identity (Problem 2, like the legacy adapter above) — not as a substitute for good naming or for splitting an interface that's grown unfocused (lesson 079).

Mistake 2 — Forgetting that an explicit member requires the interface type to call it, and being surprised at compile time

var doc = new ReportDocument();
doc.Render();   //  CS1061 — 'ReportDocument' does not contain a definition for 'Render'
// This is not a bug — it's exactly what explicit implementation is designed to do.

If you find yourself constantly casting or declaring an interface-typed local variable just to reach a member, that's a signal worth pausing on — either the member genuinely belongs on the interface-typed API you're already using elsewhere, or you reached for explicit implementation when implicit would have served the class better.

Mistake 3 — Using explicit implementation to "fix" a design that should have used interface segregation instead

A class implements one bloated interface and uses explicit implementation to hide the members it doesn't want cluttering its public surface — treating the symptom (an inconvenient member showing up) instead of the cause (the interface was too broad for this implementer in the first place).

If the real problem is that an interface is trying to do too much for one implementer, the fix from lesson 079 — splitting it into focused interfaces — is usually the better move. Explicit implementation is for genuine name collisions and deliberate audience-hiding, not a patch for an interface that needed to be segregated.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've seen explicit implementation solve a genuine collision and quietly hide a legacy detail. Let's confirm you know exactly when — and when not — to reach for it.

You now have the full toolbox — composition, multiple interfaces, segregation, and explicit implementation — for shaping honest, focused contracts. One question remains: what principle ties all of it together into a design philosophy? That's the capstone, lesson 081.

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