Template Method Pattern · Design Patterns

What is the Template Method pattern?

Template Method means: a base class fixes the order of steps in an algorithm, and lets subclasses fill in only the steps that vary.

The base method is the “template.” It calls other methods in a fixed order. Some of those are shared by everyone; others are overridden by each subclass. In plain words: the parent says “first do A, then B, then C — you may customize B.” Children never reorder the steps; they only supply the parts that differ.

This is normally an inheritance pattern — the variation happens by subclassing. Go has no classical inheritance, so its version below uses composition instead: a shared function takes the varying step as an interface. That is closer in spirit to Strategy, but the intent — one fixed skeleton, one swappable step — stays the same.

The problem it solves

Without a template, two exporters often look like twins with a few lines changed.

# CsvExporter
rows = load()
body = to_csv(rows)
write(body)

# JsonExporter
rows = load()
body = to_json(rows)
write(body)

// CsvExporter
rows = load();
body = toCsv(rows);
write(body);

// JsonExporter
rows = load();
body = toJson(rows);
write(body);

// CSVExporter
rows := load()
body := toCSV(rows)
write(body)

// JSONExporter
rows = load()
body = toJSON(rows)
write(body)

// CsvExporter
const rows = load();
const body = toCsv(rows);
write(body);

// JsonExporter
const rows2 = load();
const body2 = toJson(rows2);
write(body2);

load and write drift over time. Someone adds validation to one copy and forgets the other. Template Method makes the shared sequence real code in one place.

The template method and the step that varies

from abc import ABC, abstractmethod


class DataProcessor(ABC):
    def process(self) -> None:
        self._read_data()
        self.process_data()  # the step that varies
        self._save_data()

    def _read_data(self) -> None:
        print("Reading data...")

    @abstractmethod
    def process_data(self) -> None: ...

    def _save_data(self) -> None:
        print("Saving data...")


class CsvProcessor(DataProcessor):
    def process_data(self) -> None:
        print("Processing CSV data")


class XmlProcessor(DataProcessor):
    def process_data(self) -> None:
        print("Processing XML data")


# use
processor: DataProcessor = CsvProcessor()
processor.process()

public abstract class DataProcessor {
    // template method — final so subclasses cannot break the order
    public final void process() {
        readData();
        processData();
        saveData();
    }

    private void readData() {
        System.out.println("Reading data...");
    }

    // the step that varies
    protected abstract void processData();

    private void saveData() {
        System.out.println("Saving data...");
    }
}

public class CsvProcessor extends DataProcessor {
    protected void processData() {
        System.out.println("Processing CSV data");
    }
}

public class XmlProcessor extends DataProcessor {
    protected void processData() {
        System.out.println("Processing XML data");
    }
}

// use
DataProcessor processor = new CsvProcessor();
processor.process();

// No inheritance in Go — the template becomes a function that
// takes the varying step as an interface.
type DataSteps interface {
	ProcessData()
}

func Process(steps DataSteps) {
	fmt.Println("Reading data...")
	steps.ProcessData() // the step that varies
	fmt.Println("Saving data...")
}

type CsvProcessor struct{}

func (CsvProcessor) ProcessData() {
	fmt.Println("Processing CSV data")
}

type XmlProcessor struct{}

func (XmlProcessor) ProcessData() {
	fmt.Println("Processing XML data")
}

// use
Process(CsvProcessor{})

abstract class DataProcessor {
  process() {
    this.readData();
    this.processData();
    this.saveData();
  }

  private readData() {
    console.log('Reading data...');
  }

  // the step that varies
  protected abstract processData(): void;

  private saveData() {
    console.log('Saving data...');
  }
}

class CsvProcessor extends DataProcessor {
  protected processData() {
    console.log('Processing CSV data');
  }
}

class XmlProcessor extends DataProcessor {
  protected processData() {
    console.log('Processing XML data');
  }
}

// use
const processor: DataProcessor = new CsvProcessor();
processor.process();

The caller runs one method. The base guarantees the sequence. The subclass (or, in Go, the injected step) only implements the one part that changes.

A shop-style exporter

The same idea with a tiny catalog export — both exporters share load and write, only transform changes.

class Exporter(ABC):
    def export(self) -> str:
        rows = self.load()
        body = self.transform(rows)
        return self.write(body)

    def load(self) -> list[dict]:
        return [{"id": 1, "name": "mug"}]

    @abstractmethod
    def transform(self, rows: list[dict]) -> str: ...

    def write(self, body: str) -> str:
        return body


class CsvExporter(Exporter):
    def transform(self, rows: list[dict]) -> str:
        row = rows[0]
        return f"id,name\\n{row['id']},{row['name']}"


class JsonExporter(Exporter):
    def transform(self, rows: list[dict]) -> str:
        row = rows[0]
        return f'[{{"id":{row["id"]},"name":"{row["name"]}"}}]'

public abstract class Exporter {
    public final String export() {
        List<Map<String, Object>> rows = load();
        String body = transform(rows);
        return write(body);
    }

    protected List<Map<String, Object>> load() {
        return List.of(Map.of("id", 1, "name", "mug"));
    }

    protected abstract String transform(List<Map<String, Object>> rows);

    protected String write(String body) {
        return body;
    }
}

public class CsvExporter extends Exporter {
    protected String transform(List<Map<String, Object>> rows) {
        Map<String, Object> row = rows.get(0);
        return "id,name\\n" + row.get("id") + "," + row.get("name");
    }
}

public class JsonExporter extends Exporter {
    protected String transform(List<Map<String, Object>> rows) {
        Map<String, Object> row = rows.get(0);
        return "[{\\"id\\":" + row.get("id") + ",\\"name\\":\\"" + row.get("name") + "\\"}]";
    }
}

type Row map[string]any

type ExportSteps interface {
	Transform(rows []Row) string
}

func Export(steps ExportSteps) string {
	rows := []Row{{"id": 1, "name": "mug"}}
	body := steps.Transform(rows)
	return body // "write" step, kept simple here
}

type CsvExporter struct{}

func (CsvExporter) Transform(rows []Row) string {
	row := rows[0]
	return fmt.Sprintf("id,name\\n%v,%v", row["id"], row["name"])
}

type JSONExporter struct{}

func (JSONExporter) Transform(rows []Row) string {
	row := rows[0]
	return fmt.Sprintf("[{\\"id\\":%v,\\"name\\":\\"%v\\"}]", row["id"], row["name"])
}

abstract class Exporter {
  export(): string {
    const rows = this.load();
    const body = this.transform(rows);
    return this.write(body);
  }

  protected load(): Record<string, unknown>[] {
    return [{ id: 1, name: 'mug' }];
  }

  protected abstract transform(rows: Record<string, unknown>[]): string;

  protected write(body: string): string {
    return body;
  }
}

class CsvExporter extends Exporter {
  protected transform(rows: Record<string, unknown>[]) {
    const row = rows[0];
    return 'id,name\\n' + row.id + ',' + row.name;
  }
}

class JsonExporter extends Exporter {
  protected transform(rows: Record<string, unknown>[]) {
    const row = rows[0];
    return '[{"id":' + row.id + ',"name":"' + row.name + '"}]';
  }
}

Hooks: optional steps with a default

Sometimes a step is optional. The base provides a default (often “do nothing”) that subclasses may override — usually called a hook.

class DataProcessor(ABC):
    def process(self) -> None:
        self._read_data()
        self.process_data()
        if self.should_backup():
            self.backup()
        self._save_data()

    def should_backup(self) -> bool:
        return False  # default: skip

    def backup(self) -> None:
        print("Backup created")

    def _read_data(self) -> None:
        print("Reading data...")

    @abstractmethod
    def process_data(self) -> None: ...

    def _save_data(self) -> None:
        print("Saving data...")


class BackedUpProcessor(DataProcessor):
    def process_data(self) -> None:
        print("Processing data with backup")

    def should_backup(self) -> bool:
        return True

public abstract class DataProcessor {
    public final void process() {
        readData();
        processData();
        if (shouldBackup()) {
            backup();
        }
        saveData();
    }

    protected boolean shouldBackup() {
        return false; // default: skip
    }

    protected void backup() {
        System.out.println("Backup created");
    }

    private void readData() {
        System.out.println("Reading data...");
    }

    protected abstract void processData();

    private void saveData() {
        System.out.println("Saving data...");
    }
}

public class BackedUpProcessor extends DataProcessor {
    protected void processData() {
        System.out.println("Processing data with backup");
    }

    protected boolean shouldBackup() {
        return true;
    }
}

type DataSteps interface {
	ProcessData()
}

// Optional hook — a Steps value opts in just by implementing it.
type BackupHook interface {
	ShouldBackup() bool
	Backup()
}

func Process(steps DataSteps) {
	fmt.Println("Reading data...")
	steps.ProcessData()
	if hook, ok := steps.(BackupHook); ok && hook.ShouldBackup() {
		hook.Backup()
	}
	fmt.Println("Saving data...")
}

type BackedUpProcessor struct{}

func (BackedUpProcessor) ProcessData() {
	fmt.Println("Processing data with backup")
}

func (BackedUpProcessor) ShouldBackup() bool {
	return true
}

func (BackedUpProcessor) Backup() {
	fmt.Println("Backup created")
}

abstract class DataProcessor {
  process() {
    this.readData();
    this.processData();
    if (this.shouldBackup()) {
      this.backup();
    }
    this.saveData();
  }

  protected shouldBackup(): boolean {
    return false; // default: skip
  }

  protected backup() {
    console.log('Backup created');
  }

  private readData() {
    console.log('Reading data...');
  }

  protected abstract processData(): void;

  private saveData() {
    console.log('Saving data...');
  }
}

class BackedUpProcessor extends DataProcessor {
  protected processData() {
    console.log('Processing data with backup');
  }

  protected shouldBackup() {
    return true;
  }
}

A subclass that needs backups overrides the hook to return true. Everyone else inherits the default and stays simple.

Template Method vs Strategy

Both remove duplication around “same idea, different details.”

Template Method uses inheritance. The skeleton lives in the parent. Use it when the order of steps is an invariant you want to protect.

Strategy uses composition. You inject a behavior object. Use it when you want to swap algorithms at runtime without growing a class hierarchy.

If you find yourself with deep inheritance just to tweak one step, Strategy (or a plain function) is often healthier.

When it helps

Use it when several classes share a multi-step workflow and you want one place that defines the sequence — data import pipelines, report generation, “setup → run → teardown” flows.

It also helps when you want to stop others from reordering critical steps: mark the template method final (or, in Go, keep the skeleton function as the only entry point).

When it hurts

Inheritance couples subclasses to the parent. A clumsy base class becomes a bottleneck, and if subclasses need to radically change the flow, the template is the wrong tool.

Also avoid templates that expose many abstract methods “just in case.” Each abstract step is a burden. Prefer a short skeleton and a few clear hooks.

Practical tips

Make the template method final (or otherwise locked) when the sequence must not change.
Keep shared steps in the base; keep varying steps abstract or hooked.
Name steps so the algorithm reads like a checklist (load, transform, write).
Prefer fewer inheritance layers — this pattern is not an excuse for deep hierarchies.
If runtime swapping matters more than a fixed skeleton, switch to Strategy.

Check your understanding

Template Method in one line?
A base method runs a fixed algorithm and lets subclasses fill in selected steps.

Why lock the template method?
So subclasses cannot break the agreed order of steps.

What is a hook?
An optional overridable step with a safe default in the base.

Template Method or Strategy?
Fixed skeleton and inheritance → Template Method. Swappable behavior and composition → Strategy.

What to learn next

You have finished the course. Revisit earlier chapters any time, or pick a pattern from the syllabus to reinforce.