design-patterns

デザインパターン

意図（生成、構造、振る舞い）別に分類された26種類のデザインパターンのリファレンスです。PHP、Python、Java、C++ などでの実装、UML のガイダンス、実用的なユースケースを紹介します。

パターン一覧

生成パターン

• Abstract Factory - 具体的なクラスを指定せずに、関連するオブジェクトのファミリーを生成します → リファレンス
• Builder - 段階的なプロセスを通じて複雑なオブジェクトを組み立てます → リファレンス
• Factory Method - オブジェクト生成のインターフェースを定義し、具体的な型をサブクラスに決定させます → リファレンス
• Prototype - 具体的なクラスに依存せず、既存のオブジェクトを複製します → リファレンス
• Singleton - クラスのインスタンスが厳密に1つだけであることを保証します → リファレンス
• Object Pool - 生成コストの高いオブジェクトを再利用できるようにします → リファレンス

構造パターン

• Adapter - クライアントが期待する別のインターフェースに変換します → リファレンス
• Bridge - 抽象化と実装を分離し、両者を独立して発展させられるようにします → リファレンス
• Composite - オブジェクトをツリー構造に配置し、統一的に扱えるようにします → リファレンス
• Decorator - ラッピングを通じて、オブジェクトに新たな振る舞いを動的に重ねます → リファレンス
• Facade - 複雑なサブシステムにシンプルなインターフェースを提供します → リファレンス
• Flyweight - 多数のオブジェクト間で共通の状態を共有し、メモリ使用量を抑えます → リファレンス
• Proxy - 代理オブジェクトを介して、オブジェクトへのアクセスを管理します → リファレンス
• Private Class Data - クラス属性へのアクセスを制限します → リファレンス

振る舞いパターン

• Chain of Responsibility - ハンドラーのチェーンを通じてリクエストをルーティングします → リファレンス
• Command - リクエストを独立したオブジェクトとして表現します → リファレンス
• Interpreter - 文法表現と、それを解釈するインタープリターを定義します → リファレンス
• Iterator - 内部構造を明かさずに要素を順にたどります → リファレンス
• Mediator - 中央の調整役を通じて依存関係を整理します → リファレンス
• Memento - カプセル化を損なわずに、オブジェクトの状態を保存して復元します → リファレンス
• Null Object - 何もしないデフォルトを用意し、null チェックを不要にします → リファレンス
• Observer - 状態が変化した際に、依存するオブジェクトへ自動的に通知します → リファレンス
• State - 内部状態の遷移に応じて振る舞いを変えます → リファレンス
• Strategy - 実行時にアルゴリズムを切り替えられるようにします → リファレンス
• Template Method - アルゴリズムの骨格を定義し、具体的な手順をサブクラスに実装させます → リファレンス
• Visitor - クラスを変更せずに、オブジェクトへ操作を追加します → リファレンス

どのパターンを使うべきか

問題	パターン
関連するオブジェクトのファミリーを作成する必要がある	Abstract Factory
オプションが多く、複雑なオブジェクトを構築する	Builder
インスタンス化をサブクラスに委ねたい	Factory Method
複雑なオブジェクトのコピーが必要	Prototype
グローバルにインスタンスを厳密に1つだけにする必要がある	Singleton
互換性のないインターフェースを連携させる必要がある	Adapter
抽象化と実装を独立して変更したい	Bridge
統一的に扱う必要があるツリー構造	Composite
サブクラス化せずに責務を動的に追加する	Decorator
複雑なサブシステムのインターフェースを簡素化する	Facade
類似したオブジェクトが多数あり、メモリを過剰に消費している	Flyweight
アクセスを制御する、遅延読み込みを追加する、またはアクセスを記録する	Proxy
リクエストを処理するハンドラーが複数あり、どれが処理するか分からない	Chain of Responsibility
操作をキューに追加する、記録する、または取り消す	Command
単純な言語や文法を解釈する必要がある	Interpreter
内部構造を公開せずにコレクションを走査する	Iterator
多数の通信オブジェクト間の結合を弱める	Mediator
取り消しやスナップショットの機能が必要	Memento
1対多のイベント通知	Observer
オブジェクトの振る舞いが状態に依存する	State
実行時にアルゴリズムを切り替える必要がある	Strategy
カスタマイズ可能な手順を持つアルゴリズムの骨格	Template Method
オブジェクト構造を変更せずに操作を追加する	Visitor

ベストプラクティス

• 継承よりコンポジションを優先します。深いクラス階層を作る前に、Decorator、Strategy、Bridgeを検討してください
• 仮定上の問題ではなく、実際の問題にパターンを適用します
• 適している場合は、使用言語の最新機能を活用します。Stateには列挙型、Value Objectsには不変の値型、Strategyには第一級関数を使います
• 適切な場合はパターンを組み合わせます（たとえば、Builder + Fluent Interface、Strategy + Factory Method）
• パターンの実装は最小限に保ちます。パターンによって取り除かれる複雑さより、追加される複雑さのほうが大きい場合は、再検討してください