デザインパターンの内部構造
最終更新日 : 2008/11/23 (2008/10/19 より執筆開始)
asato <asatohan at gmail.com>
内容に関するコメント(感想、提案、書き間違いの指摘)は歓迎します。
ドラフトバージョン
個々のデザインパターンを細かな粒度の構成要素に分解し、要素間の関係付けを行うことで、それらデザインパターンの内部構造を明らかにする。明らかになった個々のパターンの内部構造に基づき、個々のパターンの不変部分・可変部分を特定する。また、関連しあうパターン間を、各パターンの内部構造の観点から関係付けを行う。そのような特定と関連付けにより、個々のパターンおよびパターン間での構造的な洗練・修正が可能となることを目指す。
- はじめに
- デザインパターンの内部構造
(2008/11/23 追加 new!!)
- Abstract Factory
- 分析対象の要素
- 分析結果 (2008/11/23 更新 update!!)
- 参考文献とリソース
- 更新履歴
- todo
はじめに
デザインパターンの内部構造
構成要素:
- 文脈: 解と解に対する制約が発生する前提。
- フォース: 解を提案するにあたって考慮する事項。
関係要素:
- 文脈->文脈: 文脈から文脈への依存関係。
- フォース->文脈: フォースから文脈への依存関係。
Abstract Factory
分析対象の要素
- 目的
- 互いに関連したり依存しあうオブジェクト群
- 具象クラス
- 具象クラスを明確にせずに生成する
- 具象クラスを明確にせずに生成するためのインタフェース
- 具象クラスを明確にせずに生成するためのインタフェースを提供
- 動機
- 別のlook-and-feel規格に容易に変更できるようにするためには、特定の規格のウィジットに関するプログラムをアプリケーションに直接書くことは避けなければならない。
- また、特定の規格に依存するクラスをアプリケーション内でインスタンス化することも、後の変更に困難をきたすことになる。
- 適用可能性
- システムを部品の生成、組み合わせ、表現の方法から独立にする
- 部品の集合が複数存在する
- 部品の集合が複数存在して、その中の一つを選んでシステムを構築する場合。
- 一群の関連する部品
- 一群の関連する部品を常に使用しなければならないようにする
- 部品のクラスライブラリを提供する
- 部品のクラスライブラリを提供する際に、インタフェースだけを公開する
- 部品のクラスライブラリを提供する際に、インタフェースだけを公開するようにして、実装は非公開にする
- 構造
- 構成要素
- AbstractFactory
- ConcreteFactory
- AbstractProduct
- ConcretetProduct
- Client
- 結果
- 具象クラスの局所化
- アプリケーションが生成するオブジェクトのクラスをプログラマが制御できるようにする
- 部品オブジェクト
- 部品オブジェクトが生成される際の責任分担
- 部品オブジェクトが生成される際の過程
- 部品オブジェクトが生成される際の責任分担の隠蔽
- 部品オブジェクトが生成される際の過程の隠蔽
- Clientオブジェクトを実装上のクラスからの分離
- Clientオブジェクトは、各インスタンスを抽象インタフェースを通して操作する
- 部分クラスの名前は ConcreteFactory クラスの実装の中に局所化される
- 部分クラスの名前は ConcreteFactory クラスの実装の中に局所化されるのでそれらが Client クラスのコード中で用いられない
- 部品の集合を容易に変更できるようになる。
- ConcreteFactory クラスは、アプリケーション内でインスタンス化される際に1回現れる
- ConcreteFactory クラスは、アプリケーション内でインスタンス化される際に1回現れるだけなので、ConcreteFactory オブジェクトの変更は容易になる
- ConcreteFactory オブジェクトを変更することで、異なる部品の集合でシステムを構成することができる
- ConcreteFactory オブジェクトは、必要とされるすべての部品を生成する
- ConcreteFactory オブジェクトは、必要とされるすべての部品を生成するのため、ConcreteFactory オブジェクトを変更することで部品の集合を一度に変えることができる。
- 部品間の無矛盾製を促進する。
- ある集合内の部品オブジェクトが協調して機能を実現するように設計されている
- ある集合内の部品オブジェクトが協調して機能を実現するように設計されているときに、アプリケーションが別の集合に属するオブジェクト同士を一緒に利用することがないようにしておく
- Abstract Factory パターンは、この制約を容易に実現する
- 新たな種類の部品への対応が困難
- 新たな種類の部品に対応できるように AbstractFactory パターンを拡張することは容易ではない
- AbstractFactory クラスのインタフェースは生成される部品の集合を固定する
- 新たな部品への対応は、インタフェースの修正が必要になる
- 新たな部品への対応は、インタフェースの修正が必要になるために、AbstractFactory クラスだけでなくそのすべてのサブクラスの修正が必要になる。
- 実装
分析結果
抽出した要素
- 文脈要素:
- 部品の種類が複数存在
- 部品の集合が複数存在(適用可能性)
- 複数存在する部品の集合から一つを選ぶ(適用可能性)
- 使用する部品の集合を変更する(結果)
- 部品の種類の追加・削除(結果)
- フォース:
文脈:部品の種類が複数存在
部品の集合が複数存在
部品の集合が複数存在して、その中の一つを選んでシステムを構築する場合
文脈:複数存在する部品の集合から一つを選ぶ
部品の集合が複数存在して、その中の一つを選んでシステムを構築する場合
文脈:使用する部品の集合を変更する
部品の集合を容易に変更できるようになる。
文脈:部品の種類の追加・削除
新たな種類の部品に対応できるように AbstractFactory パターンを拡張することは容易ではない
フォース:使用する部品の集合の容易な変更
動機:別のlook-and-feel規格に容易に変更できるようにするためには、特定の規格のウィジットに関するプログラムをアプリケーションに直接書くことは避けなければならない。
関連パターン
- Factory Method
- Prototype
- Singleton
参考文献とリソース
更新履歴
- 2008.11.23 : 「デザインパターンの内部構造」を追加。Abstract Factory の「分析結果」を更新。
- 2008.11.09 : Abstract Factory の「分析結果」を更新。
- 2008.10.29 : 図を追加。
- 2008.10.19 : 執筆開始。
todo/memo
- GoF本のどの項目に書いてることがモデルの要素に対応するのか
- static/dynamicな文脈要素
- 暗黙の要素