設計パターンを知っていても、実際の問題で候補が浮かぶとは限らない。パターンの形を覚えるだけでなく、具体的な変更要求を当てたときに、どこを変更して何を守れるかを比較する練習をしたい。
先に、守るべき条件、種類ごとに違ってよい処理、全体の手順を決める主体を整理する。その構造に対して、Template MethodやStrategyなどの名前を当てる。手順を固定する理由が曖昧なままパターンを適用すると、どの差分を拡張点にするべきかも決めにくい。
たとえばファイル変換を題材に、個別実装、Template Method、Strategyによる合成を小さく作る。それぞれへ「形式を追加する」「一形式だけ検証を変更する」「一形式だけ逐次処理にする」という同じ変更要求を当てる。変更箇所の数だけでなく、一形式の都合で他形式の契約まで変える必要があるか、必要な処理を迂回できてしまうかを見る。
共通側の変更が必要になっても、それだけで失敗とは言えない。全形式の規則が変わったのか、一形式の事情が共通側へ入り込んだのかを区別する。共通性の仮説をこのように検査すると、パターンの名前と、適用する根拠を結びつけられる。
まだ要求されていない変更は、構造を比較する材料にとどめる。練習で試したすべての変更に備える仕組みを、本番の設計へ先回りして入れる必要はない。