Template Method Pattern: Implementation Guide

1. Introduction and Core Concepts

The template method pattern is one of the most fundamental behavioral design patterns defined in the Gang of Four (GoF) catalog, and it remains indispensable for building maintainable, extensible object-oriented systems. At its core, the template method pattern defines the skeleton of an algorithm in a base class while deferring certain steps to subclasses. This allows subclasses to redefine specific parts of an algorithm without changing its overall structure, promoting code reuse and enforcing consistent workflows across different implementations.

Understanding the template method pattern is crucial because it addresses a recurring problem in software engineering: how to avoid duplication when multiple classes share the same general process but differ in details. Without this pattern, developers often copy and paste similar algorithms across classes, leading to fragile code that is difficult to maintain. The template method pattern solves this by inverting the typical inheritance relationship — instead of subclasses calling base class code, the base class orchestrates the flow and calls subclass-specific operations. This inversion is often referred to as the Hollywood Principle: "Don't call us, we'll call you."

The pattern is particularly valuable when you need to enforce a specific sequence of operations while allowing flexibility in how each operation is performed. For example, consider data processing pipelines, build systems, or document generation workflows where the high-level steps are always the same — open resource, process data, validate results, close resource — but the implementation of each step varies by data source or file format. The template method pattern provides a clean, object-oriented mechanism to encapsulate this invariant structure while making the variant parts pluggable.

Why the Template Method Pattern Matters

In modern software development, the template method pattern directly supports the DRY (Don't Repeat Yourself) and Open/Closed principles. It keeps the invariant algorithm in one place, making it easy to understand, test, and modify, while keeping the system open for extension through new subclasses. This separation of concerns improves readability and reduces the risk of introducing bugs when adding new variants.

Furthermore, the template method pattern is a cornerstone for framework design. Frameworks like Java's Spring, Python's Django, and testing frameworks such as JUnit and pytest heavily rely on this pattern to let users customize behavior by overriding hook methods without rewriting the entire execution flow. Mastering it is essential for anyone building libraries, SDKs, or extensible enterprise applications.

2. How It Works

The mechanism of the template method pattern revolves around two key participants: the Abstract Class and the Concrete Classes. The Abstract Class declares the template method itself — a concrete method that defines the algorithm's skeleton as a sequence of method calls. These method calls typically include abstract primitive operations that must be implemented by subclasses, concrete operations with default behavior, and optional hook methods that subclasses may override.

The template method is usually declared as non-overridable (final in Java, or by convention in Python) to prevent subclasses from altering the algorithm's structure. It orchestrates the workflow by invoking the primitive operations in a fixed order. For instance, a template method named processOrder() might sequentially call validateOrder(), calculateTotal(), applyDiscount(), and generateInvoice(). Subclasses cannot change this sequence, but they provide their own implementation for each step.

This structure creates a clear division between the invariant and variant parts of an algorithm. The invariant part — the control flow, error handling, logging, and resource management — lives in the abstract class. The variant part — the domain-specific logic — lives in the concrete subclasses. This separation is what makes the pattern so powerful for enforcing business rules and compliance requirements while still allowing customization.

Key Components and Terminology

To fully grasp the template method pattern, it is important to distinguish its three types of methods. Abstract primitive operations are declared abstract and must be implemented by every concrete subclass; they represent steps where every variant must provide custom logic. Concrete operations are fully implemented in the abstract class and are shared across all subclasses, often representing utility steps like logging or common validation.

Hook methods are the most nuanced component. They are concrete methods in the abstract class that provide a default implementation (often doing nothing or returning a default value) and are intended to be optionally overridden. Hooks give subclasses a way to influence the algorithm at specific points without being forced to implement every step. A common hook is shouldApplyDiscount() which returns False by default, allowing a subclass to return True to enable an optional step in the template method via a conditional check.

The Hollywood Principle in Action

The Hollywood Principle describes the inversion of control inherent in the template method pattern. High-level modules (the abstract class) control the execution flow and call low-level modules (concrete subclasses) when needed. This is the opposite of traditional procedural code where low-level code calls high-level utilities. This inversion makes the framework extensible without modification and is a foundational concept behind many modern inversion-of-control containers and event-driven architectures.

3. Implementation

Implementing the template method pattern in Python is straightforward thanks to the abc module, which provides support for abstract base classes. While Python does not have a native final keyword, we can signal that a template method should not be overridden through naming conventions, documentation, or by using the @final decorator from the typing module introduced in Python 3.8. The core idea is to create an abstract class that defines the template method and declares abstract methods for the steps that vary.

A well-structured implementation should keep the template method concise and declarative, acting as a high-level recipe. Each step should be a separate method with a single responsibility, making the code easier to test and override. Error handling and resource cleanup should be handled within the template method itself using try...finally blocks, ensuring that subclasses do not need to duplicate boilerplate code for exception safety.

Below is a canonical implementation that demonstrates the structure of the template method pattern with abstract primitive operations, concrete methods, and hooks.

from abc import ABC, abstractmethod
from typing import final

class DataMiner(ABC):
    """
    Abstract Class defining the template method for mining data
    from different sources. The template method defines the skeleton
    of the algorithm.
    """

    @final
    def mine(self) -> None:
        """Template Method: Defines the skeleton of the algorithm."""
        self.open_resource()
        raw_data = self.extract_data()
        parsed_data = self.parse_data(raw_data)
        if self.should_analyze():  # Hook method controls optional step
            self.analyze_data(parsed_data)
        self.send_report(parsed_data)
        self.close_resource()

    def open_resource(self) -> None:
        """Concrete operation: Shared implementation."""
        print("Opening connection to data source...")

    def close_resource(self) -> None:
        """Concrete operation: Shared implementation with cleanup."""
        print("Closing connection and cleaning up resources...")

    def should_analyze(self) -> bool:
        """Hook method: Default behavior, can be overridden."""
        return True

    @abstractmethod
    def extract_data(self) -> str:
        """Primitive operation: Must be implemented by subclasses."""
        pass

    @abstractmethod
    def parse_data(self, raw_data: str) -> dict:
        """Primitive operation: Must be implemented by subclasses."""
        pass

    @abstractmethod
    def analyze_data(self, data: dict) -> None:
        """Primitive operation: Subclasses provide specific analysis."""
        pass

    @abstractmethod
    def send_report(self, data: dict) -> None:
        """Primitive operation: How the report is sent varies."""
        pass

This first example establishes the abstract class. Notice how mine() is the template method that orchestrates all steps. The methods open_resource() and close_resource() are concrete operations shared by all miners, while should_analyze() is a hook that allows subclasses to skip analysis if needed. The four abstract methods force every concrete miner to define its own extraction, parsing, analysis, and reporting logic.

class CSVMiner(DataMiner):
    """Concrete Class for mining CSV files."""

    def extract_data(self) -> str:
        print("Extracting data from CSV file...")
        return "name,age,city\nAlice,30,NYC\nBob,25,LA"

    def parse_data(self, raw_data: str) -> dict:
        print("Parsing CSV data into dictionary...")
        lines = raw_data.split("\n")
        header = lines[0].split(",")
        rows = [dict(zip(header, line.split(","))) for line in lines[1:]]
        return {"type": "csv", "rows": rows}

    def analyze_data(self, data: dict) -> None:
        print(f"Analyzing {len(data['rows'])} CSV rows for trends...")

    def send_report(self, data: dict) -> None:
        print(f"Sending CSV report with {len(data['rows'])} records via email.")

class APIMiner(DataMiner):
    """Concrete Class for mining data from a REST API."""

    def extract_data(self) -> str:
        print("Extracting data from REST API endpoint...")
        return '{"users": [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]}'

    def parse_data(self, raw_data: str) -> dict:
        import json
        print("Parsing JSON response from API...")
        return json.loads(raw_data)

    def analyze_data(self, data: dict) -> None:
        print(f"Analyzing {len(data['users'])} API user objects...")

    def send_report(self, data: dict) -> None:
        print("Sending API report to dashboard via webhook.")

    def should_analyze(self) -> bool:
        """Override hook to conditionally skip analysis."""
        # Example: skip analysis if data is too small
        print("Hook check: Deciding whether to analyze...")
        return False  # Skip analysis for this miner

The second code block shows two concrete implementations. CSVMiner implements the full workflow for CSV files, while APIMiner handles JSON from an API and overrides the hook to skip the analysis step entirely. Both classes reuse the opening, closing, and overall sequencing logic from the base class, demonstrating how the template method pattern eliminates duplication while allowing behavioral variation.

# Client code demonstrating polymorphic use of the template method
def client_code(miner: DataMiner) -> None:
    """
    Client works with any subclass through the abstract interface.
    The client does not need to know the concrete type.
    """
    print(f"\n--- Starting {miner.__class__.__name__} ---")
    miner.mine()

if __name__ == "__main__":
    csv_miner = CSVMiner()
    api_miner = APIMiner()

    client_code(csv_miner)
    client_code(api_miner)

    # Output shows same skeleton, different steps and hook behavior

The client code highlights a key benefit: it can work with any DataMiner subclass without knowing its concrete type. This polymorphic behavior makes it easy to add new data sources — such as a DatabaseMiner or PDFMiner — without changing existing client code, perfectly adhering to the Open/Closed Principle.

4. Step-by-Step Example

To make the template method pattern concrete, let us walk through a complete, real-world example: building a beverage preparation framework. This is the classic example from the GoF book, but we will modernize it with Python, hooks, and validation. The algorithm for preparing any beverage follows the same steps: boil water, brew the beverage, pour into a cup, and add condiments. However, the details of brewing and condiments differ between coffee and tea.

Step one is to identify the invariant algorithm. In our beverage example, the invariant sequence is boilWater() -> brew() -> pourInCup() -> addCondiments(). This sequence should never change, regardless of the beverage type. We will encapsulate this sequence in a template method called prepare_recipe() inside an abstract CaffeineBeverage class.

Step two is to identify the variant steps. brew() and addCondiments() are clearly variant — coffee brews by filtering grounds while tea steeps a tea bag, and coffee adds sugar and milk while tea adds lemon. These will be declared as abstract methods. boilWater() and pourInCup() are invariant concrete methods shared by all beverages.

Implementing Hooks for User Customization

Step three is to add hooks for optional behavior. Not every customer wants condiments. We can add a hook method customer_wants_condiments() that returns True by default but can be overridden to ask the user or check preferences. The template method will then conditionally call addCondiments() only if the hook returns True. This demonstrates how hooks provide fine-grained control without complicating the main algorithm.

Step four is to create concrete subclasses. Coffee and Tea will inherit from CaffeineBeverage and implement the abstract methods. The Tea class might override the hook to check if the user wants lemon, while Coffee might always add condiments. This step is where the actual domain logic resides.

from abc import ABC, abstractmethod

class CaffeineBeverage(ABC):
    """Abstract Class with template method for beverage preparation."""

    def prepare_recipe(self) -> None:
        """Template Method - defines the algorithm skeleton."""
        self.boil_water()
        self.brew()
        self.pour_in_cup()
        if self.customer_wants_condiments():  # Hook with conditional
            self.add_condiments()

    def boil_water(self) -> None:
        print("Boiling water to 100°C")

    def pour_in_cup(self) -> None:
        print("Pouring into cup")

    def customer_wants_condiments(self) -> bool:
        """Hook: subclasses can override to control condiment step."""
        return True

    @abstractmethod
    def brew(self) -> None:
        pass

    @abstractmethod
    def add_condiments(self) -> None:
        pass

class Coffee(CaffeineBeverage):
    def brew(self) -> None:
        print("Dripping coffee through filter")

    def add_condiments(self) -> None:
        print("Adding sugar and milk")

    def customer_wants_condiments(self) -> bool:
        # Simulate user preference check
        preference = "yes"  # Could be input("Want condiments? (yes/no)")
        return preference.lower() == "yes"

class Tea(CaffeineBeverage):
    def brew(self) -> None:
        print("Steeping the tea bag for 3 minutes")

    def add_condiments(self) -> None:
        print("Adding lemon slice")

# Execution
print("Making coffee:")
Coffee().prepare_recipe()
print("\nMaking tea:")
Tea().prepare_recipe()

When executed, this code produces a clear trace of the algorithm. Both beverages boil water and pour into a cup identically, but their brewing and condiment steps differ. The hook in Coffee demonstrates conditional execution. This walkthrough shows how the template method pattern enforces a consistent process while keeping each variant focused solely on its unique behavior, making the system easy to extend with new beverages like HotChocolate without modifying the base algorithm.

5. Complexity Analysis

Unlike algorithmic patterns such as sorting or searching, the template method pattern does not introduce its own asymptotic complexity. Instead, its performance characteristics are determined entirely by the concrete implementations of the primitive operations. The template method itself is simply a sequencer that calls methods in order, so its overhead is minimal and constant. However, analyzing its complexity is still important for understanding system performance and for interview discussions.

The time complexity of a template method is the sum of the time complexities of its constituent steps. If a template method calls n steps with complexities O(f1), O(f2), ..., O(fn), the overall complexity is O(f1 + f2 + ... + fn), which simplifies to the complexity of the most expensive step. For example, if extract_data() is O(n) where n is the number of records, parse_data() is O(n), and analyze_data() is O(n log n), the total template method complexity is O(n log n).

Space complexity follows a similar principle. The abstract class typically holds little to no state beyond what is needed to coordinate the steps, so its space overhead is O(1). The overall space complexity is dictated by the data structures created and manipulated within the primitive operations. If each step processes data in place, the space may remain O(1) auxiliary, but if intermediate collections are created, the space will be O(n).

It is important to note that the pattern can indirectly affect performance through its structure. Because the template method enforces a fixed sequence, it may prevent certain optimizations that would reorder steps for efficiency. For example, if validation could be done lazily after partial processing to fail fast, a rigid template might force full extraction before validation. In such cases, hooks or strategy injection can be used to allow early exits. Additionally, deep inheritance hierarchies can introduce minor method dispatch overhead, but in Python this is negligible compared to the cost of I/O or data processing within the steps themselves.

6. Variations and Optimizations

While the classic template method pattern relies on inheritance, several variations adapt it to different language features and design needs. One common optimization is to reduce the number of subclasses by using composition with strategy objects for certain steps. Instead of creating a new subclass for every combination of behaviors, the abstract class can delegate specific primitive operations to injected strategy objects, blending the template method pattern with the strategy pattern for greater flexibility.

Another powerful variation is the use of hooks not just as boolean flags but as extension points that allow subclasses to insert behavior before or after major steps. For example, before_extract() and after_extract() hooks can enable logging, metrics collection, or caching without modifying the core algorithm. This approach is widely used in web frameworks where middleware needs to run at specific lifecycle points.

In Python, a functional variation can be implemented using higher-order functions and closures instead of class inheritance. The template function accepts callable parameters for each variable step, achieving the same skeleton-plus-variation structure without requiring subclasses. This is often more Pythonic and avoids deep inheritance trees, especially when the variations are simple functions rather than stateful objects.

Modern Pythonic Alternatives

Python's decorators and context managers offer elegant ways to implement template-like behavior. A decorator can wrap a function with invariant setup and teardown logic — such as opening a database transaction, executing the function, and committing or rolling back — which mirrors the template method's structure. Similarly, a context manager's __enter__ and __exit__ methods define a template for resource management, while the block inside the with statement provides the variant logic.

For performance-critical paths, an optimization is to make the template method iterative or streaming rather than batch-oriented. Instead of extracting all data into memory and then parsing it, the template can be refactored to use generators that yield chunks, reducing memory pressure from O(n) to O(1) for large datasets. The primitive operations then operate on iterators rather than complete collections.

from typing import Callable, Iterable

# Functional variation: Template as higher-order function
def process_pipeline(
    extract: Callable[[], Iterable[str]],
    parse: Callable[[str], dict],
    should_analyze: Callable[[dict], bool] = lambda x: True
) -> None:
    """Template function using composition instead of inheritance."""
    print("Opening resource...")
    for raw in extract():
        data = parse(raw)
        if should_analyze(data):
            print(f"Analyzing: {data}")
        print(f"Reporting: {data}")
    print("Closing resource...")

# Usage without creating classes
def csv_extract() -> Iterable[str]:
    return ["a,1", "b,2", "c,3"]

def csv_parse(row: str) -> dict:
    name, value = row.split(",")
    return {"name": name, "value": int(value)}

# Custom hook: only analyze if value > 1
process_pipeline(csv_extract, csv_parse, lambda d: d["value"] > 1)

This functional approach demonstrates how the essence of the template method pattern — defining a skeleton and plugging in variations — can be achieved without inheritance. It is particularly useful when the algorithm's steps are stateless or when you want to avoid class proliferation. Choosing between the classic inheritance-based approach and this composition-based variation depends on whether the variant steps require shared state and whether you need to enforce a strict type hierarchy.

7. Real-World Applications

The template method pattern is ubiquitous in real-world software, often operating behind the scenes in frameworks and infrastructure. In web servers and web frameworks, it governs the request-response lifecycle. For example, Django's class-based views define a template method called dispatch() that handles HTTP method routing, permission checks, and response rendering in a fixed order, while subclasses override methods like get(), post(), and get_context_data() to provide view-specific logic. Similarly, Java's HttpServlet uses service() as a template method that delegates to doGet() and doPost().

In databases and data engineering, the pattern is central to ETL (Extract, Transform, Load) pipelines and ORM frameworks. An abstract ETLPipeline class might define the template run() that extracts from a source, transforms records, validates, and loads into a warehouse. Concrete pipelines for different sources — Salesforce, MySQL, or S3 — implement only the extraction and transformation steps. This ensures every pipeline follows the same error handling, logging, and transactional guarantees, which is critical for data integrity.

Networking libraries also leverage the pattern for protocol handling. Consider a TCP server framework where the template method handle_connection() performs the invariant steps of accepting a socket, reading bytes, parsing a protocol frame, and closing the connection, while subclasses implement protocol-specific parsing for HTTP, WebSocket, or custom binary protocols. This keeps the complex socket management and concurrency logic centralized and bug-free.

Beyond these domains, the pattern appears in GUI frameworks, where the painting lifecycle (paint() calling paintBackground(), paintChildren()) is a template method, and in machine learning frameworks like scikit-learn, where estimators define a fit() template that calls _validate_data(), _fit(), and _post_process(). Even in embedded systems, firmware update procedures use a template method to ensure steps like checksum verification, flash erasure, and reboot are always performed in the correct order, preventing device bricking.

8. Comparison with Alternatives

Choosing the right design pattern requires understanding how the template method pattern compares to related patterns that also deal with algorithm variation. While all these patterns aim to make code flexible, they do so through different mechanisms — inheritance versus composition, compile-time versus runtime variation, and different levels of control over the algorithm's structure. Misapplying one for another can lead to rigid or overly complex designs.

The most common confusion is between the template method pattern and the strategy pattern. Both allow varying an algorithm's behavior, but they do so inversely. The template method uses inheritance to vary parts of a single algorithm's skeleton, while the strategy pattern uses composition to swap entire algorithms at runtime. If you need to enforce a fixed sequence of steps, use template method; if you need to interchange whole algorithms dynamically, use strategy. In practice, they are often combined, with a template method delegating certain steps to strategy objects.

Other alternatives include the factory method pattern, which is often implemented as a specialized template method that creates objects, and the decorator or chain of responsibility patterns, which add behavior around an algorithm rather than varying its internal steps. Understanding these trade-offs is essential for selecting the most maintainable solution.

In summary, prefer the template method pattern when you have an invariant algorithm with well-defined steps and you want to enforce that structure across all variants. Prefer strategy when the entire algorithm can be replaced and you need runtime flexibility. If your variation is solely about which class to instantiate, factory method is more appropriate. For adding orthogonal concerns like logging, caching, or authentication around an existing method without changing its core logic, decorator is the better choice. Modern Python code often favors composition over inheritance, so consider whether a functional template using callables might be cleaner than a deep class hierarchy.

9. Common Mistakes and Best Practices

One of the most frequent mistakes when implementing the template method pattern is violating the Liskov Substitution Principle by allowing subclasses to break the base class's invariants. This happens when subclasses override the template method itself or when they override concrete methods that were not intended to be overridden, thereby changing the algorithm's semantics. To prevent this, always mark the template method as @final in Python or document it clearly as not to be overridden, and keep concrete invariant methods private or final as well.

Another common pitfall is creating overly granular or overly coarse steps. If the template method is broken into too many tiny primitive operations, subclasses are forced to implement many trivial methods, leading to boilerplate and fragility. Conversely, if steps are too coarse, subclasses cannot reuse shared logic and end up duplicating code within a single large method. The best practice is to apply the Single Responsibility Principle to each step: each primitive operation should represent a logically distinct phase of the algorithm that is likely to vary independently.

Developers also often misuse inheritance where composition would be more appropriate, leading to deep, rigid hierarchies that are hard to maintain. If you find yourself creating subclasses that differ only in one or two steps out of many, or if you need to combine behaviors from multiple dimensions (e�g., data source × output format), the inheritance-based template method can cause a combinatorial explosion of classes. In such cases, consider extracting variant steps into strategy objects or using the functional variation described earlier.

Best Practices for Robust Implementation

To build a robust template method, follow these guidelines. First, keep the template method short and declarative — it should read like a high-level recipe without containing low-level logic. Second, use hooks judiciously to provide extension points without forcing subclasses to implement every method. Document each hook's purpose, default behavior, and when it is called. Third, handle all resource management, error handling, and logging inside the template method, not in subclasses, to ensure consistency. Use try...finally or context managers to guarantee cleanup.

Fourth, favor protected visibility for primitive operations (prefix with underscore in Python) to signal they are intended for subclass overriding but not for public client use. Fifth, write tests for both the abstract class's template method (using a test double subclass) and for each concrete subclass's primitive operations in isolation. Finally, consider providing a default no-op implementation for hooks and making primitive operations abstract only when every subclass must provide an implementation. This balances flexibility with safety.

• Do: Make the template method final and keep it free of conditional logic beyond hook checks.
• Do: Provide meaningful default implementations for hooks and concrete operations.
• Do: Document the algorithm's sequence and which methods are intended to be overridden.
• Don't: Let subclasses override the template method or call primitive operations out of order.
• Don't: Put business logic directly in the template method — delegate to primitive operations.
• Don't: Create deep inheritance hierarchies; prefer composition for multi-dimensional variation.

10. Interview Questions

Interviewers frequently use the template method pattern to assess understanding of object-oriented design, inheritance versus composition, and framework design. Expect questions that test both conceptual knowledge and practical implementation skills. Below are common questions with guidance on how to craft strong answers that demonstrate depth.

Q1: What is the template method pattern and what problem does it solve?

How to answer: Define the pattern as a behavioral pattern that defines the skeleton of an algorithm in a base class and lets subclasses override specific steps without changing the structure. Explain it solves code duplication when multiple classes share the same workflow but differ in details, and it enforces a consistent sequence of operations. Mention the Hollywood Principle and give a concise example like data mining or beverage preparation. Emphasize benefits: DRY, Open/Closed Principle, and framework extensibility.

Q2: How does the template method pattern differ from the strategy pattern? When would you choose one over the other?

How to answer: Clearly contrast inheritance vs. composition. Template method uses inheritance to vary parts of one algorithm with a fixed skeleton controlled by the base class; strategy uses composition to swap entire algorithms at runtime, with the client choosing the strategy. Choose template method when the algorithm's structure must be enforced and variations are known at compile time via subclasses. Choose strategy when you need runtime interchangeability of whole algorithms or want to avoid inheritance coupling. Mention they can be combined.

Q3: Can you implement a template method pattern in Python? How do you prevent subclasses from overriding the template method?

How to answer: Walk through code using abc.ABC and @abstractmethod for primitive operations, and @final from typing to mark the template method as final. Explain that Python does not enforce final at runtime strictly but linters like mypy will flag violations, and you can also use naming conventions or raise errors. Show a short snippet with a template method calling abstract and hook methods, and explain the role of each method type. Discuss Pythonic alternatives like using callables or decorators if inheritance is not desired.

Q4: What are hooks in the template method pattern and why are they useful?

How to answer: Define hooks as concrete methods in the abstract class with default (often empty) implementations that subclasses may optionally override. Explain they provide optional extension points and allow subclasses to influence the algorithm conditionally, such as skipping a step or inserting custom behavior before/after a step. Give an example like shouldApplyDiscount() or customerWantsCondiments() that controls whether addCondiments() is called. Highlight that hooks reduce the burden on subclasses by not forcing them to implement every method.

Q5: What are the drawbacks or limitations of the template method pattern?

How to answer: Discuss the main drawbacks: tight coupling through inheritance, which can lead to fragile base class problems and inflexible hierarchies; difficulty in handling multi-dimensional variation without class explosion; and the fact that the fixed skeleton can hinder optimizations that require reordering steps. Mention that it violates composition-over-inheritance preference in modern design and can make testing harder if the base class has complex state. Suggest mitigations like combining with strategy, using functional templates, or favoring composition for complex cases.