Template Method Pattern

CSC-430

Phillip Wright

Template Method

Defines the skeleton of an algorithm, deferring some steps to subclasses. Template methods let subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

Template Method II

public abstract class CaffeineBeverage{
  // ...

  public void prepare(){
    boilWater();
    brew();
    pourInCup();
    addExtras();
  }

  // ...
}

High level algorithm. Almost like pseudo code!

Template Method III

So, at a high level, we know who to make a caffeinated beverage, but we haven’t provided any details about any of the steps.

What changes if we want to make tea versus making coffee?

Do all steps change?

Template Method IV

For the steps that won’t (likely) change, we can go ahead and provide the common implementation

Template Method V

public abstract class CaffeineBeverage{
  // ...

  public void boilWater(){
    // Boil the water...
  }

  public void pourInCup(){
    // Pour into a cup
  }

  // ...
}

Template Method VI

For the remaining steps which we expect to be specific to a subclass, we can provide a simple abstract method signature.

Note that, not only do we expect them to defined in the subclass, we actually force this by making them abstract.

Template Method VII

public abstract class CaffeineBeverage{
  // ...
  
  public abstract void brew();

  public abstract void addExtras();
}

Template Method VIII

Now, we can implement specific, concrete algorithms using this template by subclassing.

Template Method IX

public class Coffee extends CaffeineBeverage{
  public void brew(){
    // Brew in a coffee specific way
  }

  public void addExtras(){
    // Add cream and other coffeeish things
  }
}

Template Method X

public class Tea extends CaffeineBeverage{
  public void brew(){
    // Brew in a tea specific way
  }

  public void addExtras(){
    // Add lemon and things
  }
}

OO Principle: Hollywood Principle

Don’t call us, we’ll call you

Hollywood Principle

• High level components call low level components
• …but without creating dependencies on them

Other Patterns

How is this similar to other patterns?

When To Use

• To implement variant and invariant parts of algorithms separately
• When common behavior needs to be factored out of several subclasses
• To restrict subclass extension via “hooks”

Implementation

• Think about what subclasses must implement, and make those steps abstract
  • … otherwise, provide a default implementation (which might do nothing!)
• Try to reduce the number of required implementations.