はじめに
各デザインパターンをどの場面で使うのか。といったことをまとめました。
生成パターン
Abstract Factory
・ Factoryクラスを切り替えることでインスタンスを切り替えることが可能
・ Xだったら、A、B、C。Yだったら、D、E、Fを返す
Builder
・ 複数のオブジェクトを生成する上で、専用のクラスを用意する際に便利
・ オブジェクトの生成が複雑な時に使う
Factory Method
・ 機能が複雑になりクラスが多くなった際に使える
・ どの具象クラスを使うのかを隠す時に使う
・ 一緒に使いたいオブジェクトを生成する際に利用
Prototype
・ 同じクラスで複数のオブジェクトを作成する際に便利です。毎回コンストラクタを使ってオブジェクトを生成することなくクローンを生成できる。clone()したいときに使う
Singleton
・ オブジェクトを一つだけ生成させるデザインパターン。
・ 1つのクラスから1つのオブジェクトだけと制限する際に使えます。
・ オブジェクトの唯一性を保証するために使う
プログラムの構造に関するパターン
Adapter
・ インタフェースに互換性の無いクラス同士を組み合わせることを目的としたパターン
・ 本来繋がっていないクラス同士を関連づける時など、利用したいインタフェースを強制的に変えたいような場合に利用できる
Bridge
・ 機能と実装を分離して、それぞれを独立に拡張することができるようにするためのパターン
・ 機能の上位クラスが、集約している実装の上位クラスに処理を委譲することによって、２つの階層を橋のように結びつけることができる
Composite
・ 器と中身を同一視することで、再帰的な構造の取り扱いを容易にすることができるパターン
Decorator
・ 飾り枠と中身を同一視することで、より柔軟な機能拡張方法を提供することができるパターン
・ 継承以外の手段で機能を追加することができる
Facade
・ 既存のクラスを複数組み合わせて使う手順を、「窓口」となるクラスを作ってシンプルに利用できるようにするパターン
Flyweight
・ 同じインスタンスを共有することで無駄なを生成を削減し、プログラム全体を軽くすることを目的としたパターン
・ 小さなオブジェクトを数多くロードする状況で効率的に処理できる
Proxy
・ 要求を代理人のオブジェクトが受け取り、処理をするようなパターン
オブジェクトの振る舞いに関するパターン
Chain of Responsibility
・ 責任者を鎖状につないでおき、いずれかの段階で、「誰か」が処理をすることを表現するようなパターン
・ メッセージを他のクラスのオブジェクトに送って処理することが可能
Command
・ 命令を表すオブジェクトをメソッドの引数にすることで、1つの引数で複数のデータと処理を伝えることができるパターン
Interpreter
・ インターフェースを使って、構文解析の結果をツリー構造で表示するパターン
Iterator
・ 要素の集まりを保有するオブジェクトの各要素に順番にアクセスする方法を提供するためのパターン
・ 集約オブジェクトの種類や実装に依存しない、統一的な走査方法を提供したいような場合に利用できる
・ forEachしたい時
Mediator
・ 適宜判断を行い指示を出す「仲裁人」の役割を果たすクラスを利用するパターン
・ クラス間の疎結合を綺麗に整理することができ、複数のオブジェクトを組み合わせて機能を実装する際に利用できる
Memento
・ 必要な情報のみを保持しておき、必要なデータのみを復元できるようなパターン
Observer
・ 通知の仕組みをより汎用的に利用できる形で提供するためのパターン
あるオブジェクトの変化を別のオブジェクトに通知させることが可能
State
・ モノではなく、「状態」をクラスとして表現するパターン
・ if文を利用することなく、状態に対応した処理を行うことができる
Strategy
・ 戦略の部分を意識して別クラスとして作成することで、柔軟でメンテナンスしやすい設計をするためのパターン
・ クラスを使う人のコードを変更することなくアルゴリズムを変更することが可能
Template Method
・ テンプレートの機能を持つクラスを作成するパターン
・ 処理の流れをテンプレート化したいような時に利用できる
Visitor
・ 受け入れる側に処理を追加することなく、処理を追加することができるパターン
・ オブジェクトに動的に機能を追加するために利用できる