Template Method Pattern - Define Skeleton, Override Steps

▶

Steps

setup

Setup: Define Base Class CaffeineBeverage

The abstract base class CaffeineBeverage is defined with the template method 'prepare_recipe' that calls steps boil_water, brew, pour_in_cup, and conditionally add_condiments. Abstract methods brew and add_condiments are declared.

💡 This step establishes the algorithm skeleton that subclasses will follow and override. Understanding this structure is key to grasping the pattern.

Line:

class CaffeineBeverage(ABC):
    def prepare_recipe(self):
        self.boil_water()
        self.brew()

💡 The template method defines the fixed sequence of steps, enforcing the algorithm's structure.

setup

Setup: Define Subclass Tea with Overrides

The Tea subclass overrides the abstract methods brew and add_condiments, and also overrides the hook method customer_wants_condiments to disable condiments.

💡 This step shows how subclasses customize specific steps and optionally disable parts of the algorithm via hooks.

Line:

class Tea(CaffeineBeverage):
    def brew(self):
        print('Steep tea bag')
    def add_condiments(self):
        print('Add lemon')

💡 Subclasses provide concrete implementations for abstract steps and can override hooks to influence optional behavior.

setup

Setup: Define Subclass Coffee with Overrides

The Coffee subclass overrides brew and add_condiments methods, but uses the default hook to include condiments.

💡 This step contrasts Coffee with Tea, showing how the hook can be left as default to include optional steps.

Line:

class Coffee(CaffeineBeverage):
    def brew(self):
        print('Brew coffee grounds')
    def add_condiments(self):
        print('Add sugar and milk')

💡 Subclasses can selectively override hooks or leave defaults to control optional steps.

traverse

Begin prepare_recipe on Tea: boil_water

Calling prepare_recipe on Tea instance starts. The first step boil_water is executed from the base class, printing 'Boil water'.

💡 This step shows the fixed first step of the template method, common to all subclasses.

Line:

def prepare_recipe(self):
    self.boil_water()

💡 The template method enforces the order of steps, starting with boiling water.

traverse

Tea: brew step override executes

The prepare_recipe method calls brew. Tea's override of brew executes, printing 'Steep tea bag'.

💡 This step demonstrates polymorphism: the subclass's brew method is called instead of the base abstract method.

Line:

def prepare_recipe(self):
    self.brew()

💡 Subclass overrides allow customizing specific steps while preserving the overall algorithm.

traverse

Tea: pour_in_cup executes from base class

Next, prepare_recipe calls pour_in_cup, which is implemented in the base class and prints 'Pour into cup'.

💡 This step shows that some steps are shared and not overridden, demonstrating reuse.

Line:

def prepare_recipe(self):
    self.pour_in_cup()

💡 Concrete steps in the base class can be reused by all subclasses without change.

compare

Tea: Check hook customer_wants_condiments

prepare_recipe calls the hook method customer_wants_condiments to decide whether to add condiments. Tea overrides this hook to return False.

💡 This step shows how hooks allow subclasses to control optional steps without changing the template method.

Line:

def prepare_recipe(self):
    if self.customer_wants_condiments():

💡 Hooks provide flexible extension points to enable or disable parts of the algorithm.

prune

Tea: Skip add_condiments due to hook

Since customer_wants_condiments returned False, prepare_recipe skips calling add_condiments for Tea.

💡 This step demonstrates how the algorithm flow can be pruned dynamically by hooks.

Line:

if self.customer_wants_condiments():
    self.add_condiments()

💡 Hooks enable subclasses to prune optional steps without modifying the template method.

traverse

Begin prepare_recipe on Coffee: boil_water

Calling prepare_recipe on Coffee instance starts. The first step boil_water executes from base class, printing 'Boil water'.

💡 This step repeats the fixed first step for Coffee, showing the shared algorithm structure.

Line:

def prepare_recipe(self):
    self.boil_water()

💡 The template method enforces the same sequence for all subclasses.

traverse

Coffee: brew step override executes

prepare_recipe calls brew. Coffee's override executes, printing 'Brew coffee grounds'.

💡 This step shows Coffee's customized brewing step replacing the abstract method.

Line:

def prepare_recipe(self):
    self.brew()

💡 Subclass overrides provide specific implementations for abstract steps.

traverse

Coffee: pour_in_cup executes from base class

prepare_recipe calls pour_in_cup, implemented in base class, printing 'Pour into cup'.

💡 This step shows reuse of base class concrete method pour_in_cup.

Line:

def prepare_recipe(self):
    self.pour_in_cup()

💡 Concrete base class methods are reused by subclasses without override.

compare

Coffee: Check hook customer_wants_condiments

prepare_recipe calls customer_wants_condiments hook. Coffee uses default implementation returning True, so condiments will be added.

💡 This step shows the hook enabling optional steps by default.

Line:

def prepare_recipe(self):
    if self.customer_wants_condiments():

💡 Hooks allow subclasses to enable optional steps by overriding or using defaults.

traverse

Coffee: add_condiments step override executes

Since hook returned True, prepare_recipe calls Coffee's add_condiments override, printing 'Add sugar and milk'.

💡 This step shows the final customized step in Coffee's preparation sequence.

Line:

if self.customer_wants_condiments():
    self.add_condiments()

💡 Subclass overrides complete the algorithm customization by providing specific condiments.

final_state

Final State: Template Method Pattern Execution Complete

Both Tea and Coffee have executed their prepare_recipe methods. Tea skipped condiments due to hook override; Coffee included condiments. The algorithm skeleton was preserved by the base class.

💡 This final step summarizes how the template method pattern enforces algorithm structure while allowing subclass customization.

💡 The pattern separates invariant algorithm steps from variant ones, promoting reuse and flexibility.

from abc import ABC, abstractmethod

class CaffeineBeverage(ABC):
    def prepare_recipe(self):  # STEP 4,9
        self.boil_water()      # STEP 4,9
        self.brew()            # STEP 5,10
        self.pour_in_cup()     # STEP 6,11
        if self.customer_wants_condiments():  # STEP 7,12
            self.add_condiments()  # STEP 8,13

    def boil_water(self):  # STEP 4,9
        print('Boil water')

    @abstractmethod
    def brew(self):  # STEP 5,10
        pass

    def pour_in_cup(self):  # STEP 6,11
        print('Pour into cup')

    @abstractmethod
    def add_condiments(self):  # STEP 8,13
        pass

    def customer_wants_condiments(self):  # STEP 7,12
        return True  # Hook method with default implementation

class Tea(CaffeineBeverage):
    def brew(self):  # STEP 5
        print('Steep tea bag')

    def add_condiments(self):  # STEP 8
        print('Add lemon')

    def customer_wants_condiments(self):  # STEP 7
        return False  # Tea without condiments

class Coffee(CaffeineBeverage):
    def brew(self):  # STEP 10
        print('Brew coffee grounds')

    def add_condiments(self):  # STEP 13
        print('Add sugar and milk')

if __name__ == '__main__':
    print('Making Tea:')
    Tea().prepare_recipe()  # STEP 4-8
    print()
    print('Making Coffee:')
    Coffee().prepare_recipe()  # STEP 9-13

📊

Template Method Pattern - Define Skeleton, Override Steps - Watch the Algorithm Execute, Step by Step

Watching each step of the template method execution reveals how inheritance and method overriding work together to enforce a consistent algorithm structure while allowing flexible customization.

Defines the template method pattern skeleton with abstract and concrete steps.

«abstract»CaffeineBeverage

+prepare_recipe()

+boil_water()

+brew()

+3 more

Subclass overrides abstract steps and hook to customize behavior.

Tea

+brew()

+add_condiments()

+customer_wants_condiments()

«abstract»CaffeineBeverage

Tea ▷ CaffeineBeverage

Subclass overrides abstract steps but uses default hook to include condiments.

Coffee

+brew()

+add_condiments()

«abstract»CaffeineBeverage

Coffee ▷ CaffeineBeverage

Template method calls concrete step boil_water from base class.

Tea

+prepare_recipe()

+boil_water()

«abstract»CaffeineBeverage

Tea ▷ CaffeineBeverage

Subclass method brew overrides abstract step.

Tea

+brew()

«abstract»CaffeineBeverage

Tea ▷ CaffeineBeverage

Base class concrete method pour_in_cup reused.

Tea

+pour_in_cup()

«abstract»CaffeineBeverage

Tea ▷ CaffeineBeverage

Hook method controls optional step execution.

Tea

+customer_wants_condiments()

«abstract»CaffeineBeverage

Tea ▷ CaffeineBeverage

Optional step pruned by hook decision.

Tea

+add_condiments()

«abstract»CaffeineBeverage

Tea ▷ CaffeineBeverage

Template method calls concrete step boil_water from base class.

Coffee

+prepare_recipe()

+boil_water()

«abstract»CaffeineBeverage

Coffee ▷ CaffeineBeverage

Subclass method brew overrides abstract step.

Coffee

+brew()

«abstract»CaffeineBeverage

Coffee ▷ CaffeineBeverage

Base class concrete method pour_in_cup reused.

Coffee

+pour_in_cup()

«abstract»CaffeineBeverage

Coffee ▷ CaffeineBeverage

Hook method controls optional step execution.

Coffee

+customer_wants_condiments()

«abstract»CaffeineBeverage

Coffee ▷ CaffeineBeverage

Subclass method add_condiments overrides abstract step.

Coffee

+add_condiments()

«abstract»CaffeineBeverage

Coffee ▷ CaffeineBeverage

Template Method pattern enforces algorithm skeleton with subclass customization via overrides and hooks.

«abstract»CaffeineBeverage

+prepare_recipe()

+boil_water()

+brew()

+3 more

Tea

+brew()

+add_condiments()

+customer_wants_condiments()

Coffee

+brew()

+add_condiments()

Tea ▷ CaffeineBeverageCoffee ▷ CaffeineBeverage

Key Takeaways

✓ The template method defines a fixed algorithm skeleton, ensuring consistent execution order.

This insight is hard to see from code alone because the flow is split across base and subclasses; visualization shows the enforced sequence clearly.

✓ Subclasses override abstract steps to customize parts of the algorithm without changing its structure.

Seeing the method calls and overrides step-by-step reveals how polymorphism enables flexible behavior.

✓ Hook methods allow subclasses to enable or disable optional steps dynamically, pruning the algorithm flow.

The conditional execution controlled by hooks is subtle in code but becomes obvious when watching the decision and pruning steps.

Practice

1. Trace the sequence of events when a player rolls the dice and lands on a ladder in a well-designed Snake and Ladder game. Which of the following best describes the correct order of internal state changes?

easy

A. Player rolls dice -> GameController calculates new position -> Board checks for ladder -> GameController updates Player position accordingly

B. Player rolls dice -> Player position updated -> Board checks for ladder -> Player position updated again if ladder found

C. Player rolls dice -> Board updates Player position directly if ladder found -> Player notified of new position

D. Player rolls dice -> Dice notifies Board -> Board updates Player position -> GameController confirms move

Solution

1. Step 1: Dice roll triggers GameController

   Dice generates number; GameController uses it to calculate tentative position.

2. Step 2: Board checks for ladder or snake

   GameController queries Board to see if new position has ladder or snake.

3. Step 3: GameController updates Player position

   Based on Board's info, GameController updates Player's position accordingly.

4. Step 4: Player position is finalized

   Player's position reflects ladder climb if applicable.

5. Final Answer:

   Option A -> Option A

6. Quick Check:

   Only GameController manages state changes; Board is queried but does not update Player directly.

Hint: GameController mediates all state changes after dice roll [OK]

Common Mistakes:

• Assuming Player updates position before Board check
• Believing Board directly updates Player position
• Thinking Dice notifies Board

2. Identify the bug in the following Builder pattern code snippet that constructs a luxury house:

medium

A. get_result method returns the wrong object

B. Constructor does not initialize the House object

C. Director does not call build_roof method

D. Line with 'pass' in build_pool method lacks adding 'Pool' part

Solution

1. Step 1: Inspect build_pool method

   The build_pool method contains only 'pass', so it does not add the 'Pool' part to the house.

2. Step 2: Check Director.construct_luxury_house calls

   The Director calls build_pool expecting the pool to be added, but due to missing implementation, it is not.

3. Final Answer:

   Option D -> Option D

4. Quick Check:

   Missing pool addition causes incomplete luxury house [OK]

Hint: Empty build_pool method -> missing part added [OK]

Common Mistakes:

• Confusing constructor initialization
• Ignoring missing method implementation

3. What is a key trade-off or limitation when using multiple inheritance to solve the Diamond Problem in object-oriented design?

medium

A. Multiple inheritance always leads to ambiguous method calls that cannot be resolved.

B. Multiple inheritance eliminates the need for Method Resolution Order (MRO).

C. Multiple inheritance reduces code reuse compared to single inheritance.

D. Using multiple inheritance can increase complexity and make the class hierarchy harder to understand and maintain.

Solution

1. Step 1: Understand the Diamond Problem

   Diamond Problem arises when a class inherits from two classes that share a common ancestor, causing ambiguity.

2. Step 2: Evaluate Multiple inheritance always leads to ambiguous method calls that cannot be resolved.

   Multiple inheritance can cause ambiguity, but languages use MRO to resolve it, so it is not always unresolved.

3. Step 3: Evaluate Multiple inheritance eliminates the need for Method Resolution Order (MRO).

   MRO is essential in multiple inheritance to resolve method calls, so multiple inheritance does not eliminate MRO.

4. Step 4: Evaluate Multiple inheritance reduces code reuse compared to single inheritance.

   Multiple inheritance generally increases code reuse by combining features from multiple classes.

5. Step 5: Correct trade-off

   Using multiple inheritance can increase complexity and make the class hierarchy harder to understand and maintain. correctly identifies that multiple inheritance increases complexity and can make hierarchies harder to maintain.

6. Final Answer:

   Option D -> Option D

7. Quick Check:

   Complexity and maintainability are key trade-offs in multiple inheritance.

Hint: Multiple inheritance = power with complexity cost

Common Mistakes:

• Believing multiple inheritance always causes irresolvable ambiguity
• Thinking MRO is unnecessary with multiple inheritance
• Assuming multiple inheritance reduces code reuse

4. What is the time complexity of notifying observers in the thread-safe observer pattern implementation where observers are stored in a dictionary mapping event types to sets of observers, and a snapshot list is created during notification?

medium

A. O(n) where n is total number of all observers across all event types

B. O(k) where k is the number of observers subscribed to the notified event type

C. O(k + n) where k is observers for event type and n is total observers

D. O(1) constant time due to hash set usage

Solution

1. Step 1: Identify the data structure and notification process

   Observers are stored per event type in sets. Notification locks and copies only the observers for the specific event type.

2. Step 2: Analyze complexity of notify()

   Notify creates a snapshot list of observers for the event type (size k) and iterates over it, so time is proportional to k, not total n.

3. Final Answer:

   Option B -> Option B

4. Quick Check:

   Notify cost depends only on observers for that event type [OK]

Hint: Notify complexity depends on observers for event type only [OK]

Common Mistakes:

• Assuming notify iterates over all observers regardless of event type

5. Suppose you want to extend the observer pattern to allow observers to receive multiple notifications for the same event type without unsubscribing (i.e., observers can be registered multiple times for the same event). Which modification to the thread-safe observer pattern implementation below correctly supports this requirement without breaking thread safety or notification correctness? Options: A) Change the observers data structure from a set to a list per event type and allow duplicates. B) Keep using a set but add a counter for each observer to track multiple subscriptions. C) Use a dictionary mapping observers to their subscription counts per event type. D) Use a queue per event type to enqueue notifications and process them asynchronously.

hard

A. Keep using a set but add a counter for each observer to track multiple subscriptions.

B. Change the observers data structure from a set to a list per event type and allow duplicates.

C. Use a dictionary mapping observers to their subscription counts per event type.

D. Use a queue per event type to enqueue notifications and process them asynchronously.

Solution

1. Step 1: Understand the requirement

   Observers can subscribe multiple times to the same event type and should receive multiple notifications accordingly.

2. Step 2: Evaluate data structure changes

   Using a set alone disallows duplicates. A list allows duplicates but is not thread-safe and inefficient for removals. A dictionary mapping observers to counts tracks multiple subscriptions safely.

3. Step 3: Choose the best approach

   Adding a counter per observer in the set (Keep using a set but add a counter for each observer to track multiple subscriptions.) or using a dictionary (Use a dictionary mapping observers to their subscription counts per event type.) can work, but adding a counter per observer in the set is simpler and keeps thread safety with minimal changes.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Counting subscriptions per observer preserves multiple notifications safely [OK]

Hint: Track subscription counts to allow multiple notifications [OK]

Common Mistakes:

• Using list causes concurrency issues and inefficient removals