You've used interfaces throughout Foundations without thinking too hard about them. It's time to think hard about them — because they're the single most important design tool in this entire module.

In Foundations, an interface probably looked like a formality: a contract with a name starting with I, implemented by one class, mostly there because a tutorial told you to. In a real codebase, interfaces do something much bigger — they're the seams along which a system can be tested, swapped, and owned by different teams without anyone stepping on anyone else's code:

// The order service's ENTIRE test suite runs in milliseconds, with zero
// network calls, zero database, zero real payment gateway — because
// every one of its dependencies is an interface, not a concrete class.
public sealed class OrderService(
    IInventoryRepository inventory,
    IPaymentGateway payments,
    IOrderNotifier notifier)
{
    public async Task<OrderResult> PlaceOrderAsync(Order order)
    {
        if (!await inventory.HasStockAsync(order.Items))
            return OrderResult.OutOfStock();

        var paymentResult = await payments.ChargeAsync(order.Total);
        if (!paymentResult.Success)
            return OrderResult.PaymentFailed(paymentResult.Reason);

        await inventory.ReserveAsync(order.Items);
        await notifier.NotifyOrderPlacedAsync(order);
        return OrderResult.Success(order.Id);
    }
}
// A test supplies FakeInventoryRepository, FakePaymentGateway, FakeOrderNotifier.
// Production supplies SqlInventoryRepository, StripeGateway, EmailOrderNotifier.
// OrderService's code is IDENTICAL in both cases — it only ever sees the interfaces.

That's the real reason interfaces matter: OrderService doesn't know or care whether it's running against a real database or a fake one, a real payment gateway or a fraud-testing stub. The interface is a seam — a place the system can be cut apart, tested in pieces, and reassembled with different concrete parts, at will.

In this lesson, you'll go deeper into interfaces: default interface methods (C# 8+), a full, honest interface-versus-abstract-class comparison, how to design interfaces specifically for testability and dependency injection, and how interface contracts function as boundaries between teams and modules — not just between classes.

A Quick Refresher, at Intermediate Depth

An interface declares a set of members — methods, properties, events, indexers — with no state and, traditionally, no implementation. Any class or struct can implement it by supplying that implementation, regardless of what else that class inherits from. You know this part. What's new at this depth is understanding why that "no state, implement from anywhere" design is so powerful, and what's changed about interfaces since C# 8.

Default Interface Methods (C# 8+)

Before C# 8, every interface member was purely abstract — every implementer had to write every method, even boilerplate that was identical everywhere. C# 8 introduced default interface methods: an interface member can now carry a body, which implementers inherit automatically unless they choose to override it.

public interface IAuditableEntity
{
    DateTime CreatedAtUtc { get; }
    DateTime? ModifiedAtUtc { get; }

    // Default interface method — a real, callable implementation, right here
    string DescribeAge()
    {
        var age = DateTime.UtcNow - CreatedAtUtc;
        return age.TotalDays < 1
            ? "Created today"
            : $"Created {(int)age.TotalDays} day(s) ago";
    }
}

public sealed class Invoice(DateTime createdAtUtc) : IAuditableEntity
{
    public DateTime CreatedAtUtc { get; } = createdAtUtc;
    public DateTime? ModifiedAtUtc { get; private set; }
    // DescribeAge() is NOT reimplemented — Invoice gets the default for free
}

IAuditableEntity invoice = new Invoice(DateTime.UtcNow.AddDays(-3));
Console.WriteLine(invoice.DescribeAge());   // "Created 3 day(s) ago"

This was added mainly to solve API evolution: a published interface used by thousands of consumers could never gain a new member without breaking every existing implementer — until now. Adding a new member with a default body doesn't break anyone; every existing implementation keeps compiling, and simply inherits the default until it chooses to override it.

Big Picture — Interfaces as Team Boundaries

In a real organization, interfaces aren't just a compiler feature — they're often the actual line where one team's ownership ends and another's begins.

Neither team needs to read the other's source code to work together correctly — they only need to agree on, and honor, the interface. That's a much stronger and more scalable form of decoupling than "please don't break my code," because the compiler enforces it.

Designing Interfaces for Testability and DI

Not every interface is equally well-designed for testing and dependency injection. A few concrete habits separate an interface that makes testing trivial from one that quietly makes it painful:

• Model behavior your caller actually needs, not everything the implementation happens to expose. IPaymentGateway should have ChargeAsync and RefundAsync — not a dozen Stripe-specific configuration methods nobody outside the payments team should call.
• Keep async signatures consistent and cancellable. A CancellationToken parameter on every I/O-bound interface member means fakes and real implementations behave predictably under test timeouts and shutdown.
• Avoid leaking implementation-specific types into the signature. A method returning StripeChargeResponse instead of a neutral PaymentResult ties every caller — and every test fake — to Stripe's shape, defeating the point of the abstraction.
• Favor several small interfaces over one that does everything — a topic lesson 079 covers in full under the name Interface Segregation.

Simple Example — Testable by Construction

public interface IClock
{
    DateTime UtcNow { get; }
}

public sealed class SystemClock : IClock
{
    public DateTime UtcNow => DateTime.UtcNow;
}

public sealed class FakeClock(DateTime fixedTime) : IClock
{
    public DateTime UtcNow => fixedTime;
}

public sealed class SubscriptionService(IClock clock)
{
    public bool IsExpired(Subscription sub) => clock.UtcNow > sub.ExpiresAtUtc;
}

// Test — no waiting for real time to pass, no flaky date-dependent assertions
var clock = new FakeClock(new DateTime(2026, 1, 1));
var service = new SubscriptionService(clock);
var sub = new Subscription { ExpiresAtUtc = new DateTime(2025, 12, 31) };
Console.WriteLine(service.IsExpired(sub));   // True — deterministic, every time

Code → Meaning → Result: Wrapping something as unassuming as "the current time" behind an interface turns an untestable dependency (real wall-clock time, different every run) into a fully controllable one. This exact pattern — a one-member interface wrapping something the .NET runtime doesn't let you fake directly — shows up constantly in production code for time, randomness, file systems, and environment variables.

Real-World Example — Testing OrderService Without Any Real Infrastructure

public interface IInventoryRepository
{
    Task<bool> HasStockAsync(IReadOnlyList<OrderItem> items, CancellationToken ct = default);
    Task ReserveAsync(IReadOnlyList<OrderItem> items, CancellationToken ct = default);
}

// A hand-written test fake — no mocking framework required for something this small
public sealed class FakeInventoryRepository : IInventoryRepository
{
    public bool StockAvailable { get; set; } = true;
    public bool ReserveWasCalled { get; private set; }

    public Task<bool> HasStockAsync(IReadOnlyList<OrderItem> items, CancellationToken ct = default) =>
        Task.FromResult(StockAvailable);

    public Task ReserveAsync(IReadOnlyList<OrderItem> items, CancellationToken ct = default)
    {
        ReserveWasCalled = true;
        return Task.CompletedTask;
    }
}

// Test — OrderService (from the hook) receives all three fakes, no real dependencies at all
var inventory = new FakeInventoryRepository { StockAvailable = false };
var service = new OrderService(inventory, new FakePaymentGateway(), new FakeOrderNotifier());

var result = await service.PlaceOrderAsync(SomeTestOrder());

Debug.Assert(result == OrderResult.OutOfStock());
Debug.Assert(!inventory.ReserveWasCalled);   // correctly never reserved stock it didn't have

Why this matters beyond "tests run fast":

• This test asserts real business logic — "don't reserve stock you don't have" — without a database, network call, or payment sandbox anywhere in sight.
• The fake is a genuinely simple class, not a complex mocking-framework setup — because the interface itself is small and focused, per the testability guidance above.
• This same seam is what makes dependency injection (lesson 081) meaningful in production: the exact same OrderService class, unmodified, runs against real infrastructure in production and fakes in tests.

Under the Hood

Abstract Class vs. Interface — the Full Comparison

Lesson 075 introduced this comparison from the abstract-class side. Here it is in full, now that you understand both tools at depth:

That last row is often the deciding factor in real systems: interfaces let two teams collaborate through a contract without either team needing to know or care what the other's classes inherit from. That's a freedom abstract classes, by their single-inheritance nature, simply can't offer.

Common Mistakes

Mistake 1 — Interfaces that leak implementation details

public interface IPaymentGateway
{
    //  Ties every implementer and every test fake to Stripe's own response shape
    Task<StripeChargeResponse> ChargeAsync(decimal amount);
}

Define a neutral PaymentResult type owned by the abstraction itself, and have StripeGateway translate Stripe's response into it — the interface should never require its callers to understand any one implementation's data shape.

Mistake 2 — Assuming default interface methods behave like abstract class defaults

Invoice invoice = new Invoice(DateTime.UtcNow);
// invoice.DescribeAge();   //  compiler error — DescribeAge() isn't visible
//                              on the Invoice type itself, only on IAuditableEntity
IAuditableEntity asInterface = invoice;
asInterface.DescribeAge();   //  works — accessed through the interface type

Remember that a default interface method is only visible when the value is referenced through the interface type — an easy trap the first time you rely on one, and a key reason to understand explicit interface implementation (lesson 080), which relies on the very same mechanism deliberately.

Mistake 3 — One interface per concrete class, with no real abstraction behind it

Generating IOrderService for OrderService, ICustomerService for CustomerService, and so on, mechanically, purely because "everything should have an interface" — often with only one implementation ever, and members that mirror the concrete class exactly.

Introduce an interface when there's a genuine reason: multiple implementations, a testing seam, or a real team boundary (echoing lesson 073's Mistake 2) — not as a reflexive naming ritual applied to every class in the project.

When Should I Use It?

• A class has an external dependency (a database, an HTTP call, the system clock, the file system) that you'll want to replace with a fake or a test double.
• Two or more genuinely different implementations of the same behavior exist or are expected — different payment gateways, different notification channels, production versus test.
• You're defining a boundary between modules, layers, or teams, where the contract needs to be agreed upon and stable, independent of either side's internal class hierarchy.

Mental Model

Key Takeaway

Check Your Understanding

Let's confirm you can reason about interfaces as production design tools, not just syntax.

You now see interfaces as design seams, not decoration — which sets up multiple interface implementation (078) and interface segregation (079) perfectly.

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