Abstract Factory パターンを考えます。

kok i

Abstract Factory パターンを考えます。

デザインパターンを調べ始めた経緯はこちらです。

今回もこちらの本を読み解いていきます。

Abstract Factoryとは日本語に直すとどのような意味になるのでしょうか？

Abstractとは、
抽象的な、理論的な、観念的な、難しい、難解な、抽象派の、アブストラクトの

引用元URL：https://ejje.weblio.jp/content/abstract

Factoryとは、工場、製造所

引用元URL：https://ejje.weblio.jp/content/factory

直訳ですが　抽象的な工場　となります。しかし抽象的な工場とは一体なんなのでしょうか？読み進めていくしかないようです。


本でのカタログにあるAbstract Factoryパターンは、パターンの目的から始まります。そして、パターンを適用する動機として仮の問題を想定し、その解決策がAbstract Factoryパターンであることを示します。その後、パターンの有効な場合・構造・特徴・実装・サンプルコード・使用例・関連するパターンと内容が続きます。

今回は"特徴"までを考えていきます。

※かなり紆余曲折することや誤った解釈をする可能性があります。その際は是非コメントをお待ちしています。よろしくお願いします。

でははじめます。

AbstractFactoryパターンの目的

互いに関連したり依存し合うオブジェクト群を、その具象クラスを明確にせずに生成するためのインタフェースを提供する。

とても難しいです。本冒頭の「近くの解説書に手を伸ばすようなことはだめである。」という一文が頭をよぎります。

この一文からなんとなく、Abstract Factoryパターンが解決することは具体的なクラスを呼ばずともオブジェクト群を呼び出せるということ でしょうか？（自分でも何を書いているのかわからなくなってきました。）

さて、ここからは本の進行通りには進みません。
理由としては自身がAbstract Factoryパターンの全体像を掴めていないためです。

先に "構造" を把握します。その後、 "特徴" を読み解き、 "パターンの有効な場合" に入っていきます。 "パターンを適用する動機" に関しては今回は用いません。例が最近ではあまり見ないツールなのでそのツールの理解で大変になってしまうためです。（ちなみに例はMotifとPresentation Managerです。ご興味のある方は検索お願いします。）

AbstractFactoryパターンの構造

画像2

引用先URL：http://www.cs.unc.edu/~stotts/GOF/hires/pat3afso.htm

図がシンプル過ぎて想像できなかったので、イメージ図を用意しました。

子ども部屋を丸ごと生産できる工場があるとします。

画像3

子ども部屋を構成するプロダクトを今回は文字を使って"概念（abstract）"を表現しています。子ども部屋を構成する具体的なプロダクトは絵を使っています。

概念の工場：子ども部屋（AbstractFactory）
・いす　　　（CreateProductA）
・おもちゃ箱（CreateProductB）
・机　　　　（CreateProductC）
・本棚　　　（CreateProductD）
といったプロダクトのセットがあります。

そして概念を参照し実際に生産（実装）される工場として
・具体的な工場①：カクカクな子ども部屋（ConcreteFactory1）
・具体的な工場②：まるまるな子ども部屋（ConcreteFactory2）

クライアントは概念の子ども部屋工場と概念のプロダクト名を呼ぶだけで、具体的なプロダクトを呼び出せるのです。

クライアント）「子ども部屋を作ろう」（Abstract Factoryの宣言）
クライアント）「まずはいすだなー」
クライアント）「いでよ　いす！」　　（AbstractProdauctA）

画像3

クライアント）「次はおもちゃ箱を呼ぼうかなー」
クライアント）「いでよ　おもちゃ箱」（AbstractProdauctB）

画像4

構成要素をまとめます。
概念の工場：AbstractFactoryクラス
　概念のプロダクト（AbstractProductオブジェクト）の生成を操作するインターフェースを宣言します。
具体的な工場：ConcreteFactoryクラス
　具体的なプロダクト（ConcreteProductオブジェクト）の生成の操作を実装します。
概念のプロダクト：AbstractProductクラス
　プロダクトの形式を操作するインターフェースを宣言します。
具体的なプロダクト：ConcreteProductクラス
　対応する具体的な工場（ConcreteFactoryオブジェクト）で生成されるプロダクトオブジェクトを定義します。
ユーザが命令を呼び出すメインのクラス：Clientクラス
　概念の工場（AbstractFactoryクラス）と概念のプロダクト（AbstractProductクラス）で定義されたインターフェースのみを使用します。

AbstractFactoryパターンの特徴

・具体的なクラス(Concrete class)を局所化できる。
具体的なクラスつまり機能の実装されるクラスをユーザが命令を呼び出すメインのクラスから分離できる。

・具体的な工場で生成されるプロダクトを容易に変更できるようになる。
具体的なクラスつまり機能の実装されるクラスで生成されるプロダクトを変更するだけで、アプリケーション中で使われている各所プロダクトが変更されます。

・具体的な工場で生成されるプロダクト間の無矛盾性・一貫性を促進する。
具体的な工場で生成されるプロダクトがアプリケーションと一緒に動作するように設計されている時に、別の具体的な工場に属するオブジェクトをアプリケーションと一緒に動作しないようにできます。

・新たな種類のプロダクトに対応することは難しい。
AbstractFactoryクラスのインターフェイスが作成可能なプロダクトのセットを固定しているからです。新しい種類の製品をサポートするには、インターフェースを拡張する必要があり、これには AbstractFactory クラスとそのすべてのサブクラスを変更する必要があります。
この問題に対する1つの解決策を次回の実装編で考えます。

AbstractFactoryパターンの有効な場合

Abstract Factoryパターンは、以下のような場合に有効です。
・システムをプロダクトの生成・組み合わせ・表現の方法に独立したい場合。
・プロダクトのセットが複数存在していて、その中の一つを選んでシステムを構築したい場合。
・関連性のあるプロダクトをその関連性を担保して使用しなければならないように設計したい場合。
・プロダクトのクラスライブラリを提供する時に、インターフェースだけ公開して実装は非公開にしたい場合。


今回はAbstract Factory パターンの構造を考えました。まだまだ理解が足りていないところも多く、自分が書いた文章なのに自分自身で難解だと感じてしまいます。これから他のパターンの理解を進めていく中でもう一度Abstract Factory パターンを考えられたらと思います。



この記事が気に入ったらサポートをしてみませんか？