Template Method is a pattern where a base class defines the overall structure of an algorithm — which steps run and in what order — but lets subclasses fill in the details of specific steps. The base class says "do A, then B, then C." Subclasses decide what A, B, and C actually do.

Think of a cooking class. The instructor says: "First, prep your ingredients. Then cook them. Then plate and serve." Every student follows the same three steps in the same order — but one student makes pasta, another makes stir-fry, and a third makes soup. The structure is fixed (prep → cook → serve); the content varies.

In code, the base class has a non-virtual method (the "template method") that calls abstract or virtual methods in sequence. Subclasses override those step methods. The template method itself can't be overridden, ensuring the algorithm structure stays intact.

Two kinds of "customizable steps" in a Template Method:

1. Abstract method — a step that must be implemented by every subclass. The base class declares it with abstract, provides no default, and the compiler forces subclasses to fill it in. Example: protected abstract string FormatReport(List<object> data);
2. Hook method — a step that can be overridden but doesn't have to be. The base class declares it with virtual and provides a default implementation (often empty or a simple no-op). Subclasses override it only if they need to. Example: protected virtual void OnReportGenerated() { }

The general rule: make steps abstract when every subclass must provide its own implementation (the template can't work without it). Make steps virtual hooks when they're optional extension points that most subclasses can safely ignore.

Building a house. Every house follows the same high-level process: lay the foundation → build the frame → add the roof → install plumbing/electrical → finish the interior. That sequence never changes — you can't install plumbing before the frame exists. But the details of each step vary wildly: a bungalow has a different frame than a two-story colonial, a modern house has different plumbing than a farmhouse.

The city's building code is the "template method" — it mandates which steps happen and in what order. The architect and builders are the "subclasses" — they customize each step within the rules. The building code doesn't care whether you're building a cabin or a mansion, as long as you follow the sequence.

If the template method is virtual, a subclass can override the entire skeleton — skipping steps, reordering them, or replacing the algorithm completely. This defeats the whole purpose of the pattern. The pattern's core guarantee is: "these steps always run in this order." If subclasses can bypass that, you have no guarantee at all.

In C#, you seal the template method by simply not marking it virtual. A non-virtual public method cannot be overridden. In Java, you use the final keyword. This way, the compiler enforces the contract — subclasses cannot break the skeleton, only customize individual steps.

BackgroundService (in Microsoft.Extensions.Hosting) is the most commonly used example. The framework handles the full service lifecycle: starting, stopping, cancellation token management, and graceful shutdown. You just override ExecuteAsync(CancellationToken) to define what your background service actually does. The "template method" is the internal StartAsync/StopAsync lifecycle that you never touch.

Other .NET examples: Stream (with Read/Write as the customizable steps), HttpMessageHandler (override SendAsync), ControllerBase in ASP.NET (the action method pipeline), and DbContext.OnModelCreating() in EF Core (the framework calls it during model building).

The decision comes down to what varies and when it varies:

1. Template Method — Use when the algorithm structure is fixed and only individual steps change. The variation is known at compile time (you pick a subclass). Best for frameworks where you control the workflow and users customize specific steps.
2. Strategy — Use when the entire algorithm is interchangeable and you need to swap it at runtime. The variation is injected via composition (pass a different strategy object). Best for business logic where behavior depends on configuration, user input, or runtime conditions.

Rule of thumb: If you're saying "always do A then B then C, but each step varies" → Template Method. If you're saying "the whole approach changes depending on the situation" → Strategy.

The Hollywood Principle says: "Don't call us, we'll call you." In Template Method, the base class is Hollywood (the studio), and the subclass is the actor. The subclass doesn't decide when its methods run — it just provides the implementations and waits. The base class's template method calls the subclass's overridden methods at the right time, in the right order.

This is a form of Inversion of Control (IoC). Instead of the subclass calling base class methods, the base class controls the flow and calls down into the subclass. The subclass never invokes the template method steps directly — it just fills them in. This inverted control flow is exactly what frameworks do: you provide the customization, the framework calls your code when it's time.

Traditionally, no — Template Method requires a method with a body (the skeleton) that calls abstract methods. Interfaces couldn't have method bodies, so abstract classes were the only option.

But since C# 8 / .NET Core 3.0, interfaces support default interface methods (DIMs). This means you can technically put a template method in an interface:

public interface IReportGenerator
{
    // Template method with default body
    void Generate()
    {
        var data = FetchData();
        var formatted = FormatReport(data);
        SaveReport(formatted);
    }

    List<object> FetchData();           // must implement
    string FormatReport(List<object> d); // must implement
    void SaveReport(string output) { }   // optional hook with default
}

However, this is rarely done in practice. The template method in an interface can't be sealed (implementations can override it), you lose the ability to store shared state, and the pattern feels unnatural. Stick with abstract classes for Template Method — that's what they're designed for.

Four approaches, from most to least practical:

1. Test concrete subclasses directly — instantiate PdfReportGenerator, call Generate(), verify the output. This tests the skeleton + steps together as a unit.
2. Create a spy/test subclass — make a test-only subclass that records which steps were called and in what order. This isolates the skeleton's control flow.
3. Test hooks independently — create a minimal subclass that overrides just the hook you care about, with trivial defaults for everything else.
4. Integration tests (last resort) — test the full pipeline against real dependencies when step interactions matter.

The spy subclass approach is especially valuable for verifying that the template method calls steps in the correct order and handles exceptions properly (e.g., if step 2 throws, does cleanup still run?).

The Yo-Yo problem happens when you have deep inheritance chains and trying to understand the code requires bouncing up and down between parent and child classes — like a yo-yo on a string. You read a method in class D, it calls base.DoWork(), so you jump to class C. That also calls base.DoWork(), so you jump to class B. And so on.

Template Method is particularly susceptible to this because the base class calls down to the subclass (step methods), and the subclass might call back up (base.SomeHook()). With multiple inheritance levels, you're constantly jumping between files trying to piece together what actually executes.

Prevention: Keep inheritance shallow (2–3 levels max). If a step needs further customization, use composition (inject a strategy) rather than adding another inheritance layer.

BackgroundService implements IHostedService, which the .NET hosting framework calls during application startup and shutdown. The template method is essentially the lifecycle: the framework calls StartAsync(), which internally calls your ExecuteAsync() override, and later calls StopAsync() for graceful shutdown.

The key methods:

• StartAsync(CancellationToken) — sealed-ish (you can override but shouldn't). Starts the background task and stores the Task reference.
• ExecuteAsync(CancellationToken) — the abstract step you override. This is where your actual work goes.
• StopAsync(CancellationToken) — triggers cancellation and awaits the task. The framework handles graceful shutdown.

You never call StartAsync or StopAsync yourself — the framework does. You just fill in ExecuteAsync. That's the Hollywood Principle at work.

Absolutely — Template Method combines well with several patterns:

1. Template Method + Strategy: The skeleton is fixed (Template Method), but one or more steps delegate to an injected strategy object. This gives you a locked workflow with runtime-swappable steps.
2. Template Method + Factory Method: One of the template steps creates an object. The subclass overrides that step to create a different concrete type. Factory Method is essentially a specialized Template Method.
3. Template Method + Observer: The template fires events (hooks) at key points. Observers subscribe to those events instead of subclassing. This decouples the notification from the algorithm.
4. Template Method + Decorator: Wrap the concrete subclass in decorators to add cross-cutting concerns (logging, caching) without modifying the template or its steps.

The classic scenario: a method with a switch statement where each case runs a similar sequence of steps with minor variations. Here's the refactoring process:

1. Identify the common skeleton — look at the switch cases. What steps are the same across all cases? That's your template method.
2. Identify the varying steps — which lines change between cases? Those become abstract or virtual methods.
3. Create the base class — move the common skeleton into a non-virtual template method. Declare abstract methods for the varying steps.
4. Create subclasses — one per switch case. Each subclass implements the varying steps for its specific case.
5. Replace the switch with polymorphism — use a factory or DI to create the right subclass based on the type, then call the template method.

// BEFORE: switch-based
void Export(string format, Data data)
{
    Validate(data);                    // same for all
    switch (format)
    {
        case "pdf":  FormatAsPdf(data); break;   // varies
        case "csv":  FormatAsCsv(data); break;   // varies
        case "xlsx": FormatAsExcel(data); break;  // varies
    }
    SaveToFile(data);                  // same for all
}

// AFTER: Template Method
abstract class DataExporter
{
    public void Export(Data data)      // sealed skeleton
    {
        Validate(data);
        Format(data);                  // polymorphic step
        SaveToFile(data);
    }
    protected abstract void Format(Data data);
}

class PdfExporter : DataExporter
{
    protected override void Format(Data data) { /* PDF logic */ }
}
// CsvExporter, ExcelExporter similarly...

The Non-Virtual Interface (NVI) pattern is essentially Template Method applied at the method level. The idea: public methods are non-virtual (they define the contract and can add pre/post processing), and virtual methods are protected (they're the customization points).

The relationship:

• Template Method — a specific GoF pattern about defining algorithm skeletons with customizable steps. It's a design pattern applied to a specific problem (multi-step algorithms).
• NVI — a general coding guideline that says every public method should be a mini template method. The public method handles invariants (validation, logging, locking), then delegates to a protected virtual method for the actual work.

In practice, NVI is Template Method scaled down to individual methods. Every public method in a well-designed base class follows this pattern: public non-virtual wrapper → protected virtual implementation.

Three rules for async Template Method:

1. Make the template method itself async — public async Task ProcessAsync(). It must return Task so the caller can await it.
2. Make all step methods return Task — protected abstract Task ValidateAsync(). Even steps that are synchronous should return Task.CompletedTask. This keeps the API uniform.
3. Never use async void — it detaches from the execution flow. The template method won't wait for the step, exceptions won't propagate, and you get silent failures.

public abstract class AsyncPipeline
{
    public async Task RunAsync(CancellationToken ct = default)
    {
        await InitializeAsync(ct);
        var data = await FetchDataAsync(ct);
        var result = await ProcessAsync(data, ct);
        await SaveAsync(result, ct);
        await CleanupAsync(ct);       // always runs (or use try/finally)
    }

    protected virtual Task InitializeAsync(CancellationToken ct)
        => Task.CompletedTask;         // optional hook
    protected abstract Task<Data> FetchDataAsync(CancellationToken ct);
    protected abstract Task<Result> ProcessAsync(Data d, CancellationToken ct);
    protected abstract Task SaveAsync(Result r, CancellationToken ct);
    protected virtual Task CleanupAsync(CancellationToken ct)
        => Task.CompletedTask;         // optional hook
}

The base constructor runs before the derived constructor. So if the base constructor calls a virtual method, and the derived class overrides it, the override runs — but the derived class's fields haven't been initialized yet (they're still null/default). This leads to NullReferenceException or incorrect behavior.

The execution order is:

1. Derived field initializers run (but NOT constructor body)
2. Base constructor body runs (calls virtual method → derived override runs)
3. Derived constructor body runs (too late!)

The fix: never call virtual methods from constructors. Move initialization into the template method itself or provide a separate Initialize() step that runs after construction is complete.

Template Method and DI have a slightly awkward relationship because DI favors interface-based composition while Template Method uses inheritance. Here's how to make them work together:

1. Register concrete subclasses directly — services.AddScoped<ReportGenerator, PdfReportGenerator>();. The DI container creates the subclass, injecting any constructor dependencies.
2. Inject dependencies into the base class constructor — the base class declares constructor parameters for shared dependencies (logger, config). Subclasses call : base(logger, config).
3. Hybrid approach: Template + Strategy via DI — the base class accepts strategy interfaces in its constructor. DI injects the right strategy implementation. The template method calls the injected strategies for specific steps.

The hybrid approach is the most DI-friendly because it reduces the inheritance depth and makes step implementations independently testable.

Pass a CancellationToken through the template method and check it between (or within) steps:

1. Pass the token to every step — protected abstract Task StepAsync(CancellationToken ct). Steps that do I/O pass it to HttpClient, DbCommand, etc.
2. Check cancellation between steps — call ct.ThrowIfCancellationRequested() between expensive steps in the template method.
3. Use try/finally for cleanup — even if cancellation throws OperationCanceledException, the cleanup step should still run.

public abstract class CancellablePipeline
{
    public async Task RunAsync(CancellationToken ct)
    {
        try
        {
            await InitAsync(ct);
            ct.ThrowIfCancellationRequested();
            await ProcessAsync(ct);
            ct.ThrowIfCancellationRequested();
            await FinalizeAsync(ct);
        }
        finally
        {
            await CleanupAsync();  // always runs, even on cancel
        }
    }
}

The Fragile Base Class problem is when changes to the base class silently break subclasses. In Template Method, this is especially dangerous because subclasses depend on the behavior of the base (step ordering, state mutations, preconditions) — not just its interface.

Three common ways it manifests:

• Reordering steps — a subclass assumes step A runs before step B (and uses state set by A). Swapping A and B breaks the subclass without any compiler error.
• Adding a new required step — inserting a new abstract method means ALL existing subclasses must implement it. With 20 subclasses, that's 20 files to update.
• Changing a hook's default behavior — subclasses that relied on the old default (without overriding it) suddenly behave differently.

Mitigations: Write integration tests that verify step order. Treat the skeleton as a public API — changes are breaking changes. Use virtual hooks (with defaults) instead of abstract methods for optional steps, so adding a new step doesn't force all subclasses to update.

Several strategies for backward-compatible evolution:

1. Add new steps as virtual hooks with defaults — instead of abstract, use virtual with a no-op or sensible default. Existing subclasses don't need to change; new ones can override if they need the new step.
2. Use the "sandwich" pattern — wrap the new step in a virtual method that defaults to calling the old behavior. This lets subclasses opt into the new behavior without breaking the old.
3. Create a new base class — ReportGeneratorV2 : ReportGeneratorBase with the new step. Old subclasses extend V1, new ones extend V2. Both V1 and V2 extend the same root.
4. Feature flag in the template — the new step is guarded by if (UseNewValidation). Subclasses opt in by setting the flag.

Option 1 is the safest and most common. The key insight: virtual with a default is always safer than abstract when evolving a template, because abstract forces all subclasses to change immediately.

In functional programming, you don't need inheritance at all. The template is a higher-order function that accepts step functions as parameters. Instead of subclassing to override steps, you pass different functions for the parts that vary.

// Functional Template Method in C#
static async Task ExportData(
    Func<Task<List<Record>>> fetch,
    Func<List<Record>, string> format,
    Func<string, Task> save)
{
    var data = await fetch();                // step 1
    if (data.Count == 0) return;             // skeleton logic
    var output = format(data);               // step 2
    await save(output);                      // step 3
}

// Usage — no classes needed!
await ExportData(
    fetch:  () => db.QueryAsync<Record>("SELECT * FROM Orders"),
    format: records => JsonSerializer.Serialize(records),
    save:   json => File.WriteAllTextAsync("export.json", json)
);

The skeleton logic (null check, step ordering) lives in the higher-order function. The varying steps are passed as lambda arguments. This is essentially Strategy pattern combined with a fixed orchestrator — the functional equivalent of Template Method.

ASP.NET Core middleware is a hybrid of Template Method and Chain of Responsibility, but it's closer to Template Method in spirit. The framework defines the pipeline structure: authentication runs before authorization, which runs before routing, which runs before your endpoint. You customize what happens at each stage, but the framework controls the order.

The similarity to Template Method:

• The framework owns the skeleton — the middleware pipeline is configured at startup and the order is fixed.
• You fill in the steps — each middleware is a customization point in the pipeline.
• The Hollywood Principle applies — the framework calls your middleware, not the other way around.

The key difference: middleware is composition-based (each middleware is an independent component that calls next()), not inheritance-based. It's Template Method's concept implemented with a different mechanism.

A production-grade ETL data pipeline using Template Method:

1. Initialize (hook) — open connections, create temp directories
2. Validate Source (hook) — check that the data source is reachable and has data
3. Extract (abstract) — read data from source (SQL, API, file, message queue)
4. Transform (abstract) — clean, normalize, map the data
5. Validate Output (hook) — check data quality, row counts, schema compliance
6. Load (abstract) — write to destination (database, data warehouse, file)
7. Notify (hook) — send success/failure notification, update monitoring dashboard
8. Cleanup (hook, in finally block) — close connections, delete temp files

Steps 3, 4, and 6 are abstract because they vary for every data source/destination. Steps 1, 2, 5, 7, and 8 are virtual hooks with sensible defaults — most pipelines need them but the default behavior is usually fine.

Multiple defense layers:

1. Don't make the template method virtual — prevents subclasses from replacing the skeleton entirely.
2. Validate step outputs in the template — after calling a step, check its return value before passing it to the next step. var data = FetchData(); ArgumentNullException.ThrowIfNull(data);
3. Use the NVI pattern — the public method validates; the protected virtual method provides the implementation. The subclass can't skip the validation.
4. Make preconditions explicit — document what each step must return and what state it must maintain. Better yet, express it in code with guard clauses.
5. Write contract tests — test that every concrete subclass satisfies the base class's expectations (non-null returns, valid state transitions, etc.).

public void Process(Order order)
{
    // Template method with invariant checks
    Validate(order);

    var total = CalculateTotal(order);
    if (total < 0) throw new InvalidOperationException(
        $"CalculateTotal returned {total} — must be >= 0");

    ChargePayment(order, total);
    SendConfirmation(order);
}

A quick principle-by-principle assessment:

• SRP (Supports) — Each subclass handles one variant. The base class handles shared structure. Clear separation of concerns.
• OCP (Supports) — Add new variants by creating new subclasses. No modification to the base class or existing subclasses needed.
• LSP (Depends) — Subclasses must honor the base class contract. If a step returns unexpected types or throws unexpected exceptions, LSP breaks. The template's invariants are the contract.
• ISP (Depends) — If the base forces too many abstract methods, subclasses must implement steps they don't need. This violates ISP. Solution: use hooks with defaults instead of excessive abstract methods.
• DIP (Caution) — Subclasses depend on the concrete base class, not an abstraction. This tight coupling is the main tradeoff. Strategy pattern is more DIP-friendly because it depends on interfaces.

Bottom line: Template Method is good for SRP and OCP, neutral on LSP and ISP (depends on your design), and slightly problematic for DIP. It's a tradeoff: you get a locked skeleton but pay with tight inheritance coupling.

When to migrate:

• You need to swap algorithms at runtime (configuration, feature flags, A/B testing)
• The inheritance hierarchy is getting deep (3+ levels — Yo-Yo problem)
• You need to combine step implementations from different subclasses (impossible with single inheritance)
• The base class is becoming a fragile dependency that breaks on every change

Migration steps:

1. Extract each abstract/virtual step into its own interface: IDataFetcher, IDataFormatter, etc.
2. Move each subclass's step implementation into a strategy class that implements the corresponding interface.
3. Change the base class from abstract to concrete. Replace inheritance with constructor injection of strategy interfaces.
4. The template method now calls _fetcher.Fetch() instead of FetchData() virtual method.
5. Wire up the strategies in DI. Old subclass combinations become DI registrations.

Template Method itself doesn't introduce threading issues — it's just method calls. But the pattern creates conditions that make threading bugs more likely:

1. Shared mutable state in the base class — If the base class has fields that steps read and write, and two threads run the template concurrently, those fields become a race condition. Step A on thread 1 writes to _currentData, then step A on thread 2 overwrites it before step B on thread 1 reads it.
2. Step ordering assumptions — The template guarantees step order within one call, but not across concurrent calls. If step B depends on state set by step A, concurrent calls interleave the state.
3. Hook side effects — Hooks that modify shared state (counters, caches, audit logs) must be thread-safe.

Mitigations: Make the template method instance stateless — pass data between steps via return values and parameters, not fields. If state is unavoidable, use a per-call context object. For singleton template method instances in DI, ensure all step implementations are thread-safe.

Both patterns process work through a sequence, but they differ fundamentally in control flow:

When to use which: Template Method when all steps must always execute in a fixed order. Chain of Responsibility when you need optional processing where any handler can handle the request and stop the chain.

A game loop is one of the most natural fits for Template Method. Every game follows the same high-level loop: initialize → [process input → update game state → render] → cleanup. But the actual input handling, game logic, and rendering differ wildly between games.

public abstract class GameBase
{
    private bool _isRunning;

    // Template method — the game loop skeleton
    public void Run()
    {
        Initialize();
        _isRunning = true;

        while (_isRunning)
        {
            var deltaTime = CalculateDeltaTime();
            ProcessInput();              // abstract — varies per game
            Update(deltaTime);           // abstract — game-specific logic
            Render();                    // abstract — rendering approach
            OnFrameComplete(deltaTime);  // hook — FPS counter, debug overlay
        }

        Cleanup();
    }

    protected abstract void Initialize();
    protected abstract void ProcessInput();
    protected abstract void Update(float deltaTime);
    protected abstract void Render();

    // Hooks with defaults
    protected virtual void OnFrameComplete(float dt) { }
    protected virtual void Cleanup() { }
    protected void Quit() => _isRunning = false;

    private float CalculateDeltaTime() { /* stopwatch logic */ return 0.016f; }
}

// Concrete game
public class SpaceInvaders : GameBase
{
    protected override void Initialize() { /* load sprites, sounds */ }
    protected override void ProcessInput() { /* read keyboard for ship movement */ }
    protected override void Update(float dt) { /* move aliens, check collisions */ }
    protected override void Render() { /* draw sprites to screen */ }
}

The beauty: the game loop structure (init, loop, cleanup) is identical for every game. Only the per-game logic changes. Adding a new game means creating one class and filling in four methods. The framework handles timing, the loop, and shutdown.