複数の種類が似た処理を持つとき、共通化には個々の処理を再利用する判断と、全体の手順を固定する判断がある。Template Methodは基底クラスで手順の骨格を定め、個別の工程を子クラスへ任せる。採用するなら、各種類にその順序を守らせる理由を説明できる必要がある。
たとえばファイル変換で「読み込み、解析、変換、出力」という順序を固定し、形式ごとの解析を差し替える。この構造は、すべての形式が各工程の入力と出力の契約を守れるという前提を持つ。大きなファイルを逐次処理する要求が加わり、読み込みと出力を交互に行う必要が出たら、個別工程の差し替えだけで対応できるかを見直す。
Strategyは、交換可能な処理を別のオブジェクトとして持つ構造をとる。コンポジションを使って解析処理を差し替えても、呼び出し元が全工程を固定していれば、手順が共通であるという前提は残る。継承から合成へ変える判断と、手順をどこまで固定する判断は別である。
インターフェースへの適合だけでは、検証の実行や処理順序までは保証できない。共通側が手順を管理すれば、その入口を通る処理について工程の呼び忘れを減らせるが、各工程の意味上の契約は置換可能性として別に確かめる必要がある。
共通性は仮説なので、必須にした工程を一種類だけ空にする必要が出たら、その工程が任意なのか、異なる手順を一つにまとめたのかを確認する。最初から任意と定めたフックが空であることとは区別したい。
https://refactoring.guru/design-patterns/template-method