Contrast the Template Method pattern with the Strategy pattern. Expert Level Developer

Related Topics: Behavioral Design Patterns, Template Method Pattern, Strategy Pattern

Direct Summary: Template Method vs. Strategy

The Template Method pattern customizes an algorithm’s steps via subclassing (at compile-time), while the Strategy pattern swaps entire algorithms dynamically via composition (at runtime).

Both Template Method and Strategy are fundamental behavioral design patterns that promote code reuse and enhance flexibility in software design. While they both deal with varying algorithms, they achieve their goals through fundamentally different mechanisms and offer distinct levels of adaptability. Understanding these differences is crucial for selecting the appropriate pattern in your software architecture.

---

Key Differences Between Template Method and Strategy Patterns

1. Mechanism: Inheritance vs. Composition

• Template Method: Relies on Inheritance

  The Template Method pattern uses inheritance to define a fixed skeleton of an algorithm in an abstract base class. This base class contains a “template method” that calls a sequence of other methods, some of which are abstract (to be implemented by subclasses) and some are concrete (already implemented). Subclasses inherit this structure and override specific abstract or “hook” methods to provide their unique implementations for certain steps, without altering the overall algorithm flow. The variations are thus hard-wired into the subclass hierarchy at design time.

• Strategy: Employs Composition and Delegation

  The Strategy pattern uses composition and delegation. It defines a family of interchangeable algorithms, each encapsulated in its own concrete strategy class that implements a common interface or abstract class. A “Context” object (the client) holds a reference to a specific strategy object and delegates the execution of the algorithm to it. This design allows for dynamic swapping of algorithms at runtime, as the Context object can change its associated strategy object.

2. Flexibility and Customization Timing: Compile-time vs. Runtime

• Template Method: Compile-time Customization

  Customization in the Template Method occurs when you create subclasses. The specific variations of the algorithm’s steps are bound at compile time through the choice of which concrete subclass to instantiate. If you need to change the fundamental structure of the algorithm (the sequence of steps) or introduce a new variation for a specific step, you typically need to create a new subclass or modify existing ones, often requiring recompilation.

• Strategy: Runtime Flexibility

  With the Strategy pattern, the client can choose and change algorithms during program execution. This offers significant adaptability, allowing the system to respond to changing conditions, user preferences, or external factors without requiring code changes or recompilation. The algorithm can be swapped on the fly, providing greater runtime dynamism.

3. Purpose and Goal: Structure vs. Selection

• Template Method: Common Structure with Variations

  The Template Method aims to define a common algorithm structure (a blueprint or workflow) while allowing subclasses to provide variations for specific steps within that structure. It ensures that the invariant parts of an algorithm are fixed, while the variant parts are left to subclasses to implement. Think of it as a “recipe” with placeholder steps that can be filled in differently.

• Strategy: Selecting Different Algorithms

  The Strategy pattern focuses on encapsulating different algorithms that perform the same task and making them interchangeable. It allows the client to select the appropriate algorithm based on context without modifying the client’s code. Think of it as a “toolbox” containing different tools to achieve the same objective.

4. Impact on Design Principles

• Template Method: Primarily adheres to the Open/Closed Principle by being “open for extension” (new variations via subclasses) but “closed for modification” (the overall algorithm skeleton is fixed in the base class).
• Strategy: Also adheres to the Open/Closed Principle, allowing new strategies to be added without modifying the client code. It strongly promotes separation of concerns by isolating algorithm variations from the client logic, making the code cleaner and more modular.

---

Illustrative Examples and Scenarios

To solidify your understanding, let’s explore practical analogies and concrete C# code examples.

Analogies for Understanding

• Template Method (Baking a Cake):

  Imagine baking a cake. The overall process (mixing dry ingredients, mixing wet ingredients, combining, baking, frosting) is the template. However, the specific *type* of flour, flavorings, or frosting (the variant steps) are decided when you choose a specific recipe (subclass). Once you start, the core baking sequence is fixed; you can’t suddenly decide to deep-fry the cake instead of baking it.

• Strategy (Payment at Checkout):

  Consider choosing a payment method at checkout (credit card, PayPal, bank transfer). The *act of paying* is constant, but the *method* used can be swapped dynamically based on user preference or availability. You decide which specific payment *strategy* to use *at that moment* of payment, and you can change it for your next purchase.

Concrete Code Scenarios (C#)

Template Method Example: Report Generation

Imagine a system that generates various types of reports (e.g., PDF, CSV, HTML). The overall process for generating any report involves fetching data, formatting the header, formatting the body, and formatting the footer. While the sequence is fixed, the specific implementation of each formatting step differs per report type.

// Abstract base class defining the Template Method
public abstract class ReportGenerator
{
    // The Template Method: defines the skeleton of the algorithm
    public void GenerateReport()
    {
        Console.WriteLine("--- Starting Report Generation ---");
        FetchData();
        FormatHeader();
        FormatBody();
        FormatFooter();
        Console.WriteLine("--- Report Generation Complete ---");
    }

    // Abstract methods to be implemented by subclasses (variant steps)
    protected abstract void FetchData();
    protected abstract void FormatHeader();
    protected abstract void FormatBody();
    protected abstract void FormatFooter();

    // Hook method (optional, can have a default implementation)
    // protected virtual void AddMetadata() { /* Default empty implementation */ }
}

// Concrete subclass for PDF reports
public class PdfReportGenerator : ReportGenerator
{
    protected override void FetchData() { Console.WriteLine("Fetching data for PDF report..."); }
    protected override void FormatHeader() { Console.WriteLine("Formatting PDF header."); }
    protected override void FormatBody() { Console.WriteLine("Formatting PDF body content."); }
    protected override void FormatFooter() { Console.WriteLine("Formatting PDF footer."); }
}

// Concrete subclass for CSV reports
public class CsvReportGenerator : ReportGenerator
{
    protected override void FetchData() { Console.WriteLine("Fetching data for CSV report..."); }
    protected override void FormatHeader() { Console.WriteLine("Formatting CSV header (e.g., column names)."); }
    protected override void FormatBody() { Console.WriteLine("Formatting CSV body (e.g., comma-separated values)."); }
    protected override void FormatFooter() { Console.WriteLine("Formatting CSV footer (e.g., summary row)."); }
}

// Usage Example:
// ReportGenerator pdfGen = new PdfReportGenerator();
// pdfGen.GenerateReport();
//
// Console.WriteLine("\n");
//
// ReportGenerator csvGen = new CsvReportGenerator();
// csvGen.GenerateReport();

In this scenario, the `GenerateReport` method defines the fixed sequence, while subclasses like `PdfReportGenerator` and `CsvReportGenerator` provide the specific implementations for each step.

Strategy Example: Discount Calculation

Consider an e-commerce platform that needs to apply various discount strategies (e.g., percentage-based, fixed amount, buy-one-get-one). The discount calculation logic can change dynamically based on promotions or user selections.

// Strategy Interface: Defines the common operation for all strategies
public interface IDiscountStrategy
{
    decimal ApplyDiscount(decimal originalPrice);
}

// Concrete Strategy 1: Percentage Discount
public class PercentageDiscountStrategy : IDiscountStrategy
{
    private readonly decimal _percentage; // e.g., 10 for 10%
    public PercentageDiscountStrategy(decimal percentage) { _percentage = percentage; }

    public decimal ApplyDiscount(decimal originalPrice)
    {
        Console.WriteLine($"Applying {_percentage}% discount.");
        return originalPrice * (1 - _percentage / 100);
    }
}

// Concrete Strategy 2: Fixed Amount Discount
public class FixedAmountDiscountStrategy : IDiscountStrategy
{
    private readonly decimal _fixedAmount; // e.g., 5.00 for $5 off
    public FixedAmountDiscountStrategy(decimal fixedAmount) { _fixedAmount = fixedAmount; }

    public decimal ApplyDiscount(decimal originalPrice)
    {
        Console.WriteLine($"Applying fixed discount of ${_fixedAmount}.");
        return originalPrice - _fixedAmount;
    }
}

// Context Class: Uses a strategy
public class ShoppingCart
{
    private IDiscountStrategy _discountStrategy;
    public decimal OriginalPrice { get; private set; }

    public ShoppingCart(decimal initialPrice)
    {
        OriginalPrice = initialPrice;
    }

    // Allows changing the strategy at runtime
    public void SetDiscountStrategy(IDiscountStrategy strategy)
    {
        _discountStrategy = strategy;
    }

    // Delegates the discount calculation to the current strategy
    public decimal GetFinalPrice()
    {
        if (_discountStrategy != null)
        {
            return _discountStrategy.ApplyDiscount(OriginalPrice);
        }
        Console.WriteLine("No discount applied.");
        return OriginalPrice;
    }
}

// Usage Example:
// ShoppingCart cart = new ShoppingCart(100m);
//
// // Apply a percentage discount
// cart.SetDiscountStrategy(new PercentageDiscountStrategy(10)); // 10% off
// Console.WriteLine($"Final price with 10% off: ${cart.GetFinalPrice()}"); // Output: 90
//
// // Apply a fixed amount discount dynamically
// cart.SetDiscountStrategy(new FixedAmountDiscountStrategy(15m)); // $15 off
// Console.WriteLine($"Final price with $15 off: ${cart.GetFinalPrice()}"); // Output: 85
//
// // Or no discount
// cart.SetDiscountStrategy(null);
// Console.WriteLine($"Final price with no discount: ${cart.GetFinalPrice()}"); // Output: 100

Here, the `ShoppingCart` (Context) can dynamically switch discount behaviors by setting different `IDiscountStrategy` implementations at runtime without modifying its own core logic.

---

When to Use Which Pattern

Choose Template Method when:

• You have a fixed, invariant algorithm, but some specific steps within that algorithm can vary.
• You want to control the exact sequence of operations in an algorithm.
• You want to allow subclasses to implement specific details of an algorithm without changing the overall structure of that algorithm.
• The variations are determined at compile time (by creating specific subclasses), and runtime flexibility for the overall algorithm sequence is not a primary concern.

Choose Strategy when:

• You have multiple algorithms that perform the same task, and you need to swap them dynamically at runtime.
• You want to encapsulate algorithm variations independently of the client that uses them.
• You want to avoid complex conditional statements (like `if`/`else-if` or `switch` cases) for selecting behavior based on context.
• The choice of algorithm needs to happen at runtime based on context, user input, or changing conditions.

---

Conclusion

Both the Template Method and Strategy patterns are powerful tools for managing complexity and promoting code reuse in object-oriented design. The fundamental distinction lies in their approach to variation:

• The Template Method uses inheritance to vary steps within a fixed, overarching algorithm.
• The Strategy pattern uses composition to vary the entire algorithm itself at runtime.

Understanding this core difference is crucial for selecting the appropriate pattern to build flexible, maintainable, and scalable software systems, especially for expert-level developers navigating complex architectural decisions.