目的

 

• 同じようなものを組み合わせて一つのものを作り上げるが、場合に応じて各部品の詳細を変更したい

 

適用例

 

• GUI部品を集めたパッケージでは、OSごとに部品の動作を変える必要がある

 

ただのFactoryで生じる問題

 

Windows向けのトグルボタン、Mac向けのトグルボタン、Windows向けのスクロールバー、Mac向けのスクロールバー、…などと、具体的な部品を生成するFactoryクラスをそれぞれ作成する方法には、次のようなデメリットがある。

• 似たような処理が複数箇所に現れる
• 新たな対応OSを追加する際、各部品の定義と組み立て処理を一から書かなくてはならない

 

OSに関わらず構成要素はほぼ同一なのだから、各部品と組み立て手順の概略を抽象クラスとして定義しておいて、それを継承するようにすれば、OSによる違いを記述するだけで済む。

 

実装のポイント

 

1. 部品ごとに、その概要を示すインターフェース（AbstractProduct）を定義
2. それらを継承して、具体的に部品を作成するクラス（ConcreteProduct）を作成
3. 部品の組み立て方の概略を示すインターフェース（AbstractFactory）を定義
4. それを継承して、具体的に部品を組み立てるクラス（ConcreteFactory）を作成
5. クライアント側（Client）のコードでは、AbstractFactoryインターフェースで宣言されているメソッド名を用いて製品を受け取るようにする

 

日本にあるマクドナルドでバーガーを買う時、『日本人向けのバーガーが欲しい』とわざわざ言うことは無い。
日本の客にとってのただのバーガーは、店側で日本人向けに仕立てられている。

 

メリットを享受できるシチュエーション

 

• 各構成要素と、その組み合わせが決まっている場合（一緒に使用すべきでない部品どうしを誤って組み合わせることがなくなる）

 

デメリットが露呈するシチュエーション

 

• 構成要素がしょっちゅう増える場合（構成要素を追加する場合は、AbstractFactoryと全サブクラスに追記が必要になる）