gof-template-method

1行での概要

基底メソッドでアルゴリズムの骨格を定義し、一部の手順をサブクラスに委ねます。これにより、アルゴリズムの構造を変えずに、サブクラスが特定の手順を再定義できます。

このスキルを使う場面

• 2つ以上のクラスが全体として同じ手順に従いながら、1つか2つの手順だけが異なる場合（Beckの「コーヒーも紅茶も淹れる」という例）。
• ワークフローの順序は固定されているものの、特定の段階がユースケースによって異なる場合（例：形式ごとにトークン化の手順が異なるパーシングパイプライン）。
• 横断的なフレームワークのフックが必要な場合：基底クラスがライフサイクルメソッドを提供し、サブクラスが必要なものをオーバーライドします（SpringのJdbcTemplate、JUnitのsetUp／tearDown）。

このスキルを使わない場面

• 変化するのが骨格内の手順ではなく、アルゴリズムそのものである場合は、gof-strategyを使います。
• 変化する手順が1つだけで、その変化も小さい場合は、サブクラスよりも関数パラメーターやラムダのほうが簡潔です。
• 基底クラスが継承のボトルネックとなり、サブクラスがテンプレート外の処理を実行できなくなる場合は、抽象化が硬直しすぎている兆候です。

コアコンテンツ

TemplateMethodは基底クラスのメソッドで、通常はfinalまたはオーバーライド不可です。このメソッドは一連の手順を呼び出します。その一部は基底クラスで実装され、残りは抽象メソッド、またはサブクラスがオーバーライドする「フック」メソッドです。

base.run():
    step1()         # final, implemented in base
    step2Abstract() # abstract — subclass must provide
    step3Hook()    # default no-op — subclass may override
    step4()         # final, implemented in base

手順には3つの種類があります。

• 具象 — 基底クラスで完全に実装されます。
• 抽象 — サブクラスが実装する必要があります。
• フック — デフォルトの動作（多くの場合、何もしないか、妥当なデフォルト動作）を持ち、サブクラスはオーバーライドできます。

「ハリウッドの原則」――「こちらから連絡するので、連絡しないでください」――は、このパターンをフレームワークのレベルで表現したものです。基底クラスが適切なタイミングでサブクラスのオーバーライドを呼び出し、サブクラスはワークフローを進めるために基底クラスを呼び出すことはありません。

判断のヒント

• 骨格が共通で、手順が異なる場合に使います。変化する手順が1つだけなら、サブクラスではなく関数パラメーターを検討してください。
• サブクラスがワークフローを壊せないように、テンプレートメソッドをfinal（またはオーバーライド不可）にします。
• 抽象手順（必ずオーバーライドする）とフック手順（オーバーライドしてもよい）を区別し、それぞれを明記します。
• サブクラスが複雑な処理を行うために、次々と多くの手順をオーバーライドする必要がある場合、テンプレートは硬直しすぎています。

アンチパターン

• 「テンプレート」がオーバーライド可能な手順を多数含む巨大なメソッドになっているテンプレートメソッド。このパターンの利点である柔軟性が失われます。
• サブクラスでテンプレートメソッド自体をオーバーライドすること。パターンの目的に反します。
• サブクラスでオーバーライドした手順からsuper.step1()を呼び出すこと。サブクラスが基底クラスの内部実装に依存します。

関連項目

• gof-strategy — 手順だけでなく、アルゴリズム全体が変化する場合に使います。
• gof-factory — Factory MethodはTemplate Methodの一例です（アルゴリズムが具体的な型の選択をサブクラスに委ねます）。
• gof-kotlin-idioms — Kotlinのopen／finalのデフォルト設定ではTemplate Methodが明示されます。また、変化する手順が1つか2つの場合、サブクラスベースのテンプレートより高階関数が適していることもよくあります。

参考資料

• Head First Design Patterns（第2版）、第8章（「アルゴリズムのカプセル化：Template Methodパターン」） — Coffee／Teaの例を使った定番の解説。