What is abstraction in object-oriented programming, and how is it different from encapsulation? How do you design a good abstraction in C#, and what does a leaky or premature abstraction look like?

1. Levels of abstraction

Abstraction isn't only interfaces — it's how code is layered:

• A well-named method (CalculateGst(invoice)) abstracts its body.
• A class abstracts a concept (Invoice).
• A module or bounded context abstracts a business capability (Billing).
• An API abstracts a service.

The Single Level of Abstraction Principle: a method should read at one level — either orchestration (ValidateOrder(); ReserveStock(); Charge();) or detail (string parsing, SQL), not both mixed.

2. Abstractions in C#

3. Deep vs shallow modules

John Ousterhout (A Philosophy of Software Design) describes a good abstraction as a deep module: a simple interface hiding a lot of functionality. File.ReadAllTextAsync(path) is deep — one call, hiding buffering, encoding detection, OS APIs. A shallow module has an interface almost as complex as its implementation — e.g. a pass-through IOrderRepository whose methods mirror DbSet one-to-one. Shallow abstractions add cognitive load without hiding complexity.

4. Where to put the abstraction: Dependency Inversion

The consumer owns the interface. If Ordering needs payments, IPaymentGateway lives in Ordering's application layer, and StripePaymentGateway lives in infrastructure and depends on it. This keeps the domain free of provider details and lets you replace the provider without touching business logic. Putting the interface in the provider's project ("interface per class") inverts nothing.

5. Testing as a signal

If testing a class requires mocking five interfaces with deep setups, either the abstractions are too fine-grained (mocking implementation details) or the class has too many responsibilities. Good abstractions make tests simpler: fake the boundary (IPaymentGateway, TimeProvider, IClock), use real objects inside. .NET 8's TimeProvider is a nice BCL example of an abstraction introduced specifically for a real seam (time).

6. Evolving abstractions

• Adding a member to an interface breaks implementers (default interface methods mitigate this for libraries).
• Prefer adding new interfaces (IPaymentGatewayV2 or a capability interface like ISupportsPartialRefunds) to bloating existing ones.
• For internal code, refactor freely — abstractions in applications should evolve with understanding.

Try it yourself

1. Find an interface in your codebase with a single implementation and no test usage; consider removing it.
2. Find a repository returning IQueryable<T> and list what callers need to know about EF Core to use it safely.
3. Rewrite a provider-shaped interface in domain language and map exceptions at the boundary.
4. Identify one method mixing orchestration and details, and split it into levels.

// Abstraction in the caller's terms; no SDK types leak out
public interface IPaymentGateway
{
    Task<PaymentResult> ChargeAsync(Money amount, string cardToken, CancellationToken ct);
    Task<PaymentResult> RefundAsync(string paymentId, Money amount, CancellationToken ct);
}

public abstract record PaymentResult
{
    public sealed record Approved(string PaymentId) : PaymentResult;
    public sealed record Declined(string Reason) : PaymentResult;
}

public readonly record struct Money(decimal Amount, string Currency);

// Adapter: hides HTTP, SDK, retries and provider error codes
public sealed class StripeGateway(StripeClient client) : IPaymentGateway
{
    public async Task<PaymentResult> ChargeAsync(Money amount, string cardToken, CancellationToken ct)
    {
        try
        {
            var charge = await client.CreateChargeAsync(
                (long)(amount.Amount * 100), amount.Currency.ToLowerInvariant(), cardToken, ct);
            return new PaymentResult.Approved(charge.Id);
        }
        catch (StripeCardException ex)
        {
            return new PaymentResult.Declined(ex.DeclineCode ?? "card_declined");  // translated
        }
    }

    public Task<PaymentResult> RefundAsync(string paymentId, Money amount, CancellationToken ct) =>
        throw new NotImplementedException();
}

// Caller works at one level of abstraction
public sealed class CheckoutService(IPaymentGateway payments, TimeProvider clock)
{
    public async Task<string> CheckoutAsync(Cart cart, string cardToken, CancellationToken ct)
    {
        var result = await payments.ChargeAsync(cart.Total, cardToken, ct);
        return result switch
        {
            PaymentResult.Approved a => $"Paid {a.PaymentId} at {clock.GetUtcNow():O}",
            PaymentResult.Declined d => $"Declined: {d.Reason}",
            _ => throw new UnreachableException()
        };
    }
}