8 The Template Method and Strategy Design Patterns

This chapter explains how two industry-proven design patterns—Template Method and Strategy—help structure applications that must manage multiple algorithms. Rather than being drop-in code, patterns are reusable models you tailor to your problem. Using a sports domain, the chapter contrasts baseline implementations with pattern-based refactorings, showing how to eliminate duplication, improve clarity, and make behavior easier to extend and modify over time.

Template Method addresses algorithms that follow a fixed sequence of steps where some steps are shared and others vary. The chapter starts with duplicated report-generation logic for different sports and then refactors to an abstract superclass that defines the workflow while implementing common steps (like headers and footers) and delegating variable steps (data acquisition, analysis, and report body) to subclasses. The result is a clear algorithm outline, reduced duplication, adherence to the Open-Closed Principle, and better encapsulation of what changes, all while preserving the required order of operations.

Strategy targets families of interchangeable algorithms that should be swappable at runtime. The initial inheritance-based approach hardcodes player-recruitment and venue-reservation behaviors and repeats logic. The refactoring composes a sport from independent strategy objects (player and venue), enabling reuse (e.g., a shared stadium strategy), runtime flexibility (swap a venue on the fly), and looser coupling. The chapter closes with guidance: use Template Method when a stable workflow needs step-level customization via inheritance, and use Strategy when you must switch entire algorithms via composition to keep clients independent from algorithm variants.

The public method generate_report() of class BaseballReport calls its private methods that perform the steps to generate a baseball game report. It depends on class BaseballData to generate random test data for the report.

The public method generate_report() of class VolleyballReport calls its private methods, which perform the steps to generate a volleyball game report. It depends on class VolleyballData to generate random test data for the report.

This version of the application is modeled from the Template Method Design Pattern. The abstract superclass GameReport outlines the steps in the proper order for the algorithm to generate a report. It implements the common steps _print_header() and _print_footer() and delegates the remaining steps _acquire_data(), _analyze_data(), and _print_report() to the BaseballReport and VolleyballReport subclasses. The public template method generate_report() in the superclass calls the step methods in the proper order. The grayed-out portions of the diagram haven’t changed logically from figures 8.1 and 8.2.

The generic model of the Template Method Design Pattern. We can compare it with figure 8.3. The methods of the abstract superclass AlgorithmOutline outlines the steps of the algorithm. Method template_method() calls the methods representing the steps in the correct order. The superclass implements the common steps and delegates implementing the varying steps to its concrete subclasses. Table 8.1 shows how the example application applies the pattern.

The first version of our sports application. Superclass class Sport has abstract methods representing algorithms that each of the subclasses Baseball, Football, and Volleyball must implement to recruit players and reserve a venue.

This version of the application is modeled from the Strategy Design Pattern for the sport teams and venues. The player family of algorithms implement the PlayerStrategy interface, and the venue family of algorithms implement the VenueStrategy interface. Class Sport uses has-a relationships to aggregate the algorithms. Each player and venue algorithm has a strategy() method. The Baseball, Football, and Volleyball subclasses are now much simpler, and each one sets the _SPORT_TYPE, _player_strategy and _venue_strategy instance variables of the Sport superclass.

The generic model of the Strategy Design Pattern. Compare to figure 8.6. Table 8.2 shows how the example application applies the pattern.

• The Template Method Design Pattern defines the skeleton or outline of an algorithm and defers the implementation of some of the steps to subclasses. It lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.
• The Template Method Design Pattern relies on inheritance, the is-a relationship.
• The Strategy Design Pattern encapsulates each algorithm in a family of algorithms and makes them interchangeable. At run time, an application can choose which algorithm to use.
• The Strategy Design Pattern uses composition, the has-a relationship. The client class is loosely coupled from the strategy subclasses.

FAQ