判断ガイド: 抽象化すべきか・デザインパターンを使うべきか¶

抽象化の判断フロー¶

Q1. 抽象化の対象は「知識の重複」か「字面の重複」か?
    → 知識(同じ仕様が2か所)──> 即座に一元化([DRY](../01_design_basics/09_yagni_kiss_dry.md))
    → 字面(たまたま似ている)──> Q2へ
Q2. 同じ形が3回目に現れたか?
    → 2回まで ──> コピペのまま待つ(2例では共通部分を見誤る)
    → 3回目 ──> 具体例が揃った。共通部分を確信を持って抽出できる
Q3. 抽象の失敗コストを見積もったか?
    間違った抽象 > 重複(戻すコストが高い)。抽出は「全例を見て」行う

パターン適用の判断フロー¶

Q1. 今、破綻シグナルが出ているか?
    ・同じ型分岐のswitchが複数関数に複製 → [State](../03_design_patterns/state.md)/[Strategy](../03_design_patterns/strategy.md)/ポリモーフィズム
    ・フラグの組み合わせ地獄 → [FSM](../04_game_patterns/state_machines.md)
    ・変更が毎回複数ファイルに波及 → [SRP](../02_solid/srp.md)/[Observer](../03_design_patterns/observer.md)
    ・生成分岐の複製 → [Factory](../03_design_patterns/factory_method.md)
    ・SDK型の全域侵食 → [Adapter](../03_design_patterns/adapter.md)
    → シグナルなし ──> 適用しない(パターンは予防接種ではなく治療)
Q2. そのパターンの「使わない場面」に該当しないか?(各パターンページの当該節を確認)
Q3. パターンなしの簡潔案(関数分割・データ化・switch集約)と比較したか?
    → パターン適用は「比較の勝者」として選ぶ。デフォルト採用しない

判断材料¶

適用するシグナル: 各ケーススタディの「破綻する過程」(第11部)と同じ症状が自分のコードに出ている
適用しないシグナル: 「勉強したから使ってみたい」/仕様が固まっていない(抽象の軸を外す)/チームがそのパターンを読めない(保守者の語彙も設計制約)

例外(先に抽象化してよいもの)¶

変更コストが非対称な決定は3回ルールの例外: セーブ形式のバージョン(ケース06)、公開API、通信プロトコル、サウンドのID化(ケース11)、入力の意図構造体(ケース01)——いずれも「安い保険・高い後悔」型。

トレードオフ¶

得: 変更の局所化、拡張の受け口、共通語彙(「ここObserverで」が通じる)
失: 間接化と読解コスト、抽象の軸を外したときの二重コスト(剥がして作り直し)、「パターンを使った」という満足感が設計検証を止める危険

実践のコツ¶

パターン名でなく問題名で会話する: 「Strategyを使おう」より「アルゴリズムの差し替えが3種あるので分離しよう」——手段が目的化するのを防ぐ
適用したら、ページの「過剰設計になる例」と自分のコードを見比べる習慣を

理解度チェック¶

「3回ルール」の根拠(2例では何が分からないか)を説明できますか。
3回ルールの例外となる決定の共通性質は?
「パターンは治療であって予防接種ではない」とはどういう意味ですか。

前: 継承かコンポジションか | カテゴリ目次 | 次: イベント・DI・Singletonの判断