🧩 過剰抽象・早すぎる一般化（Simple is better than complex）
🧭 はじめに
このページでは、「将来の拡張」を理由に今のコードを不必要に複雑化してしまうアンチパターンを整理する。Python の Zen がいう Simple is better than complex は、「雑に書け」という意味ではない。必要十分な構造に留めよという設計原則である。
🎯 ねらい
- まだ存在しない要件のために抽象レイヤを作ることのコストを可視化する
- 「拡張しやすさ」と「読みやすさ」の混同を解消する
❓ 問題の定義
- 将来起きるか分からない変更に備えて、抽象・DI・Factory・Strategy を先に入れる
- 結果として、今読む人が理解に余計な労力を払う
拡張性は価値だが、予測はしばしば外れる。
🧪 よくある症状
- Interface / 抽象クラスがあるが 実装が1つ
- 使われていないフック・オプションが大量に存在
- DI の配線や Factory が 処理の本質より目立つ
❌ 悪い例
「一応将来対応」のための過剰設計
StorageProvider抽象を用意- 実装は
LocalStorageのみ - 設定・Factory・DI が増え、処理の流れが見えない
実装が1つしかない抽象は、しばしばノイズになる。
✅ 良い例
まずは素直に書く
- 直接
LocalStorageを使う - 変更が発生したら、変化点だけを抽象化する
抽象は「薄く・局所的」に
- クラスではなく関数境界で切る
- モジュール分割で責務を分ける
抽象は「必要になってから」でも遅くない。Python は後付けのリファクタリングが得意。
🧠 設計の要点
- 抽象化の目的は 重複削減ではなく、変化の隔離
- 「将来変わるかも」ではなく **「過去に実際に変わったか」**で判断する
変更履歴（Git log）は、将来予測より信頼できる設計材料。
🧰 チェックリスト
- 実装が1つしかない抽象が多すぎないか
- 抽象を外すと、どれだけ読みやすくなるか
- その抽象は 過去の変更に基づいているか
- 今の要件を説明するのに、何枚の図が必要か
🏁 まとめ
- Simple は Primitive ではない
- 複雑さは「必要になった瞬間」に追加する
- 読みやすさは、将来の変更コストを下げる最短経路
未来のために現在を犠牲にしない。 それが Python 的な設計である。