導入
パターンは「使えば良くなる魔法」ではありません。必要ないのに導入すると、かえって複雑になります。ここでは代表的なアンチパターン（避けたい設計）と、「パターンをいつ使うか」の指針を整理します。手を動かすより、判断の物差しを持ち帰る回です。
説明
代表的なアンチパターンを知っておくと、レビューで「これは危ない」と気づけます。
flowchart TB
A["神クラス（God Object）<br/>1クラスが何もかも抱える"] --> R1["→ 責務で分割（SRP）"]
B["スパゲッティコード<br/>制御が絡み合って追えない"] --> R2["→ 関数・クラスに分解"]
C["マジックナンバー<br/>意味不明な定数が直書き"] --> R3["→ 定数・enum に名前を付ける"]
D["コピペプログラミング<br/>同じコードが各所に増殖"] --> R4["→ 共通化・メソッド抽出"]
style A fill:#ffebee
style B fill:#ffebee
style C fill:#ffebee
style D fill:#ffebee
代表的なアンチパターン
- 神クラス（God Object）：1つのクラスがデータも処理も何もかも抱え、巨大化して手が付けられない。→ 単一責任の原則（SRP）で責務ごとに分割。
- スパゲッティコード：
goto的な飛び回りやネストの深いifで制御が絡み合い、読めない。→ 早期return・メソッド抽出で平らにする。 - マジックナンバー／マジックストリング：
if (status == 3)のような意味不明の直書き。→enumや名前付き定数にする。 - コピペプログラミング：同じロジックが各所に複製され、修正漏れが起きる。→ メソッド・クラスに共通化（ただしDRYのやりすぎにも注意）。
- 黄金のハンマー：「このパターン／技術が好きだから何にでも使う」。→ 問題に合った手段を選ぶ。
パターンをいつ使うか
パターンは「今ある問題」を解くために選びます。将来を過剰に見越して先回り実装すると、使われない抽象だけが残ります（過剰設計＝YAGNI違反）。
- まずは素直で単純なコードで書く
- 同じ変更が繰り返し必要になった／重複が痛くなったときに、対応するパターンへリファクタリングする
- パターン名は「意図を伝える共通語彙」。チームで名前を共有できることに価値がある
- SOLID原則（オブジェクト指向コース）は、どのパターンにも通底する土台
「パターンを覚えたら使いたくなる」——その気持ちをぐっと抑え、問題が現れてから手を伸ばすのが、良い設計への近道です。
まとめ
- アンチパターン（神クラス・マジックナンバー等）を知ると危険に気づける
- パターンは「今ある問題」に対して選ぶ。先回りの過剰設計は避ける
- 単純に書き、重複や変更の痛みが出てからリファクタリングする