ようこそ。睡眠不足なプログラマのチラ裏です。

GoFなデザパタ小まとめ ちょっとした復習的な何か


■生成に関するパターン

Singleton
プログラム上、クラスのインスタンスが1つ(あるいは制限数ぶん)しかない事を保証し、
そのインスタンスにアクセスするためのグローバルな方法を提供する。

Builder
複合オブジェクトについて、その作成過程を表現形式に依存しないものにすることで、
同じ作成過程で異なるオブジェクトを生成できるようにする。
考え方はTemplateMethodパターンとだいぶ似ている。

Factory Method
インスタンスの生成を行うインターフェイスだけをabstractメソッドに定義しておき、
実際のインスタンス生成はそのサブクラスで行う。
最小規模なTemplate Methodパターンといったところ。

Prototype
既にあるインスタンスをコピーして、新しいインスタンスを生成するパターン。
クラスをnewして作成する事が難しい場合や、
同じようなクラスが多すぎる場合に1つにまとめたいときなどに利用。

Abstract Factory
互いに関連したり依存し合うオブジェクト群を、
その具象クラスを明確にせずに生成するためのインターフェイスを提供する。
簡単にいうと、抽象的に生成できる仲良しなクラスのインスタンスを作る方法。


■構造に関するパターン

Adapter
必要とするクラスが、必要とするインターフェースと異なる場合に、
コネクタの役割を果たすクラスを1枚かぶせて目的のインターフェースに合わせる。
委譲を使ったものと、継承を使ったものの2種類で実現することが可能

Bridge
抽出されたクラスと実装を分離することで、それらを独立に変更できるようにする。
機能の継承と、実装の継承を分けて考えるパターン。
機能のクラス階層と、実装のクラス階層は一番上のクラスで委譲を利用して結びつける。
委譲を使用して結びつけるので、クラスとクラスの結びつきが弱くなり、実装を容易に換える事ができる。

Composite
枝と葉の同一視。種類の異なる似たデータを同一視する事で、再帰を定義する。
例えばFileとDirectoryの再帰をたどる例を考えるとその例がそのままCompositeパターンとなる。

Decorator
飾り枠と中身を同一視することで、オブジェクトの責任を動的に追加するパターン。
このパターンでは、サブクラス化するよりも柔軟な拡張方法が提供される。
機能を必要に応じて動的に追加する場合等に使用できる

Facade
サブシステム内に存在する複数のインターフェイスに1つの統一インターフェイスを与えるパターン。
複雑に呼ばなければいけないインターフェイスを単純なインターフェイスとしてまとめ、
利用者(開発者)にわかり易いようにする。

Flyweight
再利用可能なインスタンスは使い回すパターン。
Singletonパターン等を使用して、インスタンスを使い回して共有することで、
多数の細かいオブジェクトを効率よくサポートする。

Proxy
あるオブジェクトへのアクセスを制御し、そのオブジェクトの代理または入れ物を提供する。
Proxyは、重たい処理が本当に必要になるまでは処理を実行せず、本当に必要になった場合にのみ実行する。
例えば、ディスクに書き込む必要が出るまではメモリ上に書き込んでおき、必要になった段階でディスクに書き込むなど。


■振る舞いに関するパターン

Iterator
繰り返している集約オブジェクトの内部構造を意識せずに、
その要素に順次アクセスする繰り返し処理を提供するパターン。

Template Method
大まかな処理の流れとして、親クラス(抽象クラス)でアルゴリズムのスケルトンを定義し、
実際の処理部分をサブクラスで実装するパターン。
同じような処理を複数個作りたいケースに使用できる。

Strategy
アルゴリズムをカプセル化し、それらを交換可能とするパターン。
オブジェクトの振る舞いを動的に変更したいようなケースに用いる。

Visitor
VisitorがAcceptorを呼び、AcceptorがVisitorを呼ぶ事によって自分自身を呼ぶ(ダブルディスパッチ)。
データと処理を明確に分ける事を目的とされる場合に用いる。構文木などを操作する場合等によく使用する。

Chain of Responsibility
要求に対する処理のたらいまわしのパターン。
データを処理するクラスをデータの種類によって複数に分け、
どのクラスを使用して処理するかを呼び出す側が意識しない。
クラスチェーンを使用して順番に呼び出し、各クラスが処理できるかを判断し処理を行う。
処理する内容を動的に変更したい場合に、クラスチェーンを変化させる事によって柔軟に条件を変更できる

Mediator
オブジェクトの相互作用をカプセル化するオブジェクトを定義する。
Mediatorパターンではオブジェクト同士がお互いに明示的に参照しあうことがないようにし、
クラス間の結合度を低めることを促進する。

Observer
状態の変化をObserverが監視(実際には通知する)し、処理を1箇所にまとめておくパターン。
あるオブジェクトの状態が変化したとき、それに依存する全てのオブジェクトに自動的に通知し、
それらが更新されるようにオブジェクト間に一対多の依存関係を持たせるパターン。

Memento
undo, redo, history, snapshot等の機能を実現したい場合に、
オブジェクトの状態をクラスのインスタンスとして保存しておくパターン。

State
状態をクラスで表現する。また、状態を表すクラスにロジックをもたせる事によって、
実行する内容をクラスを変更する事で切り替えるパターン。
クラスで表現しない場合と比べて、if文が減らすことができ、保守と拡張性を高める。

Command
要求をオブジェクトとしてカプセル化するパターン。
異なる要求や、要求からなるキューやログにより、クライアントをパラメータ化する。
Mementoパターンと組み合わせることで、処理の取り消しや、リプレイなどをサポートすることできる。

Interpreter
ミニ言語を実装し、そのミニ言語で処理を記述するパターン。
言語に対して、文法表現と、それを使用して文を解釈するインタプリタを一緒に定義する。
検索エンジン等に使われている検索用の表現等も、このミニ言語を実装している。