C# Abstract Classes: When to Use Them vs Interfaces

Sometimes you don't just want to define a contract — you want to hand out some of the implementation too. That's what an abstract class is for.

Picture a payment processing module with three gateways: Stripe, PayPal, and a bank-transfer ACH processor. All three need to log every attempt, retry on transient failure, and record a transaction record afterward — that part is identical, word for word, in all three. But the actual "send this to the payment network" step is completely different for each one. If you model this purely with an interface, you'll write the exact same logging-and-retry code three times:

//  With just an interface, this exact block gets copy-pasted into
// StripeGateway, PayPalGateway, and AchGateway — three times, with
// three chances to drift out of sync when someone fixes a bug in one.
public class StripeGateway : IPaymentGateway
{
    public PaymentResult Charge(PaymentRequest request)
    {
        _logger.Log($"Charging {request.Amount:C} via Stripe...");
        for (int attempt = 0; attempt < 3; attempt++)
        {
            try { return SendToStripe(request); }
            catch (TransientGatewayException) when (attempt < 2) { /* retry */ }
        }
        throw new PaymentFailedException("Stripe charge failed after retries.");
    }
    // ...
}

An abstract class solves exactly this: it lets you write the shared logging-and-retry code once, in one place, while still forcing every gateway to supply its own "send to the network" step. It's a base class with a piece deliberately left blank — and the compiler refuses to let anyone forget to fill it in.

In this lesson, you'll learn what abstract class and abstract methods actually guarantee, how they differ from a plain virtual method, when an abstract base class is the right call versus an interface, and — since interfaces are the very next lesson — a full, honest comparison between the two.

What Is an Abstract Class?

An abstract class is a class you can never instantiate directly — it exists purely to be inherited from. It can contain fully implemented methods and fields, just like a normal class, but it can also declare abstract members: methods (or properties) with a signature but no body at all, which every non-abstract subclass is required to implement.

public abstract class PaymentGateway
{
    // Fully implemented — shared by every subclass, written once
    protected readonly ILogger Logger;
    protected PaymentGateway(ILogger logger) => Logger = logger;

    // Abstract — NO body, and every concrete subclass MUST provide one
    protected abstract PaymentResult SendToNetwork(PaymentRequest request);
}

// var gateway = new PaymentGateway(logger); //  compiler error: cannot instantiate an abstract class

Two rules define the whole feature: an abstract class cannot be new'd up on its own, and an abstract member has no implementation at all in the class that declares it — only in a class that overrides it can it get one.

Why Does It Exist? — Shared Implementation + Enforced Contract

Without abstract classes, you're stuck with two unsatisfying choices when several related types need to share some logic but must each supply their own version of one specific piece:

An abstract class is the tool built specifically to combine both: real, inherited implementation for the parts that are genuinely identical, plus a compiler-enforced guarantee — not a runtime hope — that every concrete subclass fills in the parts that aren't.

Big Picture

The logging-and-retry logic lives in exactly one place. Fix a bug in it once, and all three gateways get the fix automatically. Forget to implement SendToNetwork in a new gateway, and the code simply doesn't compile — there's no way to ship that mistake.

Abstract Methods vs. Virtual Methods

Both participate in the same runtime dispatch mechanism you learned in lesson 074 — but they make very different promises to a subclass author:

This is the essential difference: virtual says "here's a reasonable default, override if you want something different." abstract says "there is no reasonable default — you must decide."

Simple Example

public abstract class ReportSection
{
    public string Title { get; }
    protected ReportSection(string title) => Title = title;

    // Concrete: identical for every section type
    public string Render() => $"## {Title}\n{RenderBody()}\n";

    // Abstract: every section decides its own body content
    protected abstract string RenderBody();
}

public sealed class SummarySection(string title, string summaryText) : ReportSection(title)
{
    protected override string RenderBody() => summaryText;
}

public sealed class TableSection(string title, IReadOnlyList<string> rows) : ReportSection(title)
{
    protected override string RenderBody() => string.Join("\n", rows);
}

// Usage
ReportSection[] sections =
[
    new SummarySection("Overview", "Revenue grew 12% quarter over quarter."),
    new TableSection("Top Products", ["Widget A - 1,204 units", "Widget B - 980 units"])
];

foreach (var section in sections)
    Console.WriteLine(section.Render());   // Render() is inherited; RenderBody() is polymorphic

Code → Meaning → Result: Render() is written once and never repeated. RenderBody() has no default because there genuinely isn't one — a summary and a table don't share any sensible rendering logic. The compiler would refuse to compile SummarySection if it forgot to implement RenderBody().

Real-World Example — The Payment Gateway Hierarchy, in Full

public abstract class PaymentGateway(ILogger logger, ITransactionStore store)
{
    protected readonly ILogger Logger = logger;

    // Concrete — the algorithm's shape is fixed and shared by every gateway.
    // Non-virtual on purpose: no subclass should be able to skip retry or logging.
    public PaymentResult Charge(PaymentRequest request)
    {
        Logger.Log($"Charging {request.Amount:C} via {GatewayName}...");

        for (int attempt = 1; attempt <= 3; attempt++)
        {
            try
            {
                var result = SendToNetwork(request);
                store.Record(request, result);
                return result;
            }
            catch (TransientGatewayException ex) when (attempt < 3)
            {
                Logger.Log($"Attempt {attempt} failed transiently: {ex.Message}. Retrying...");
            }
        }

        throw new PaymentFailedException($"{GatewayName} charge failed after 3 attempts.");
    }

    // Abstract — every gateway MUST supply its own identity and network call.
    protected abstract string GatewayName { get; }
    protected abstract PaymentResult SendToNetwork(PaymentRequest request);
}

public sealed class StripeGateway(ILogger logger, ITransactionStore store, IStripeClient client)
    : PaymentGateway(logger, store)
{
    protected override string GatewayName => "Stripe";

    protected override PaymentResult SendToNetwork(PaymentRequest request) =>
        client.CreateCharge(request.Amount, request.Currency, request.CardToken);
}

public sealed class AchGateway(ILogger logger, ITransactionStore store, IAchClient client)
    : PaymentGateway(logger, store)
{
    protected override string GatewayName => "ACH";

    protected override PaymentResult SendToNetwork(PaymentRequest request) =>
        client.InitiateTransfer(request.Amount, request.BankAccountNumber);
    // ACH transfers settle in 1-3 business days — SendToNetwork here returns
    // a "pending" result rather than an immediate confirmation, and that's
    // fine: the shared Charge() logic doesn't care HOW settlement happens.
}

Why this is the right shape for an abstract class:

• The retry-and-record algorithm in Charge() is genuinely identical across every gateway — a textbook case for shared implementation, not duplication.
• GatewayName and SendToNetwork have no meaningful default — there's no "generic" way to talk to a payment network, so abstract correctly forces every subclass to decide.
• A shared constructor (via the primary constructor's base parameters) means every gateway is guaranteed to have a logger and a transaction store — the abstract class establishes that invariant once.
• Adding a new gateway (say, a wire-transfer processor) means writing one small class with two members — the retry/logging logic is never touched, never retested, never at risk.

Under the Hood

Common Confusion — Abstract Classes vs. Interfaces

Since C# 8 introduced default interface methods, an interface can also carry a body for some of its members — which makes the boundary look blurrier than it used to be. It isn't, once you look at what each can actually hold:

The single-inheritance limit is the most consequential difference in practice: because a class can extend only one abstract class, choosing an abstract base "spends" that class's one inheritance slot. An interface never costs you that slot — you can implement a dozen of them.

Common Mistakes

Mistake 1 — Using an abstract class purely for the contract, with no shared implementation

//  Nothing here is shared — every member is abstract. This "spends"
// the derived class's one inheritance slot for zero benefit.
public abstract class INotificationChannel_Wrong
{
    public abstract string ChannelName { get; }
    public abstract Task SendAsync(string recipient, string message);
}

If a base type has no real implementation to share, it should be an interface — INotificationChannel — precisely as seen in lesson 073's notification service. Reserve abstract classes for when there's genuine shared code to write once.

Mistake 2 — Marking a member abstract when a sensible default actually exists

Forcing every subclass to reimplement something that's genuinely the same 95% of the time creates needless repetition and gives each implementation a chance to diverge by accident.

Give it a virtual default implementation instead, and let the rare subclass that needs something different override it. Reserve abstract for members with no reasonable default at all.

Mistake 3 — Reaching for an abstract class when the real need is multiple capabilities on one class

abstract class AuditableEntity and abstract class CacheableEntity — a class that needs to be both auditable and cacheable can't inherit from both; C# doesn't allow multiple base classes.

Model each capability as its own interface (IAuditable, ICacheable) — lesson 078 covers exactly this pattern of implementing several interfaces on one class.

When Should I Use It?

• There's a genuine, stable "is-a" relationship and real, non-trivial code that every subclass would otherwise duplicate (a shared algorithm, shared state, a shared constructor invariant).
• You want to force every subclass to supply specific behavior, with a compile-time guarantee rather than a runtime NotImplementedException waiting to happen.
• The set of subclasses is reasonably closed and internal to your codebase — abstract classes work best when you control both the base and the derived types.

Mental Model

Key Takeaway

Check Your Understanding

Let's confirm you can reason about when abstract classes earn their keep — and when they don't.

You can now tell, in seconds, whether a base type belongs as an abstract class or an interface — which sets up sealed classes (076) and the deep dive into interfaces (077) perfectly.