Abstract Factory

• 関連したオブジェクト(部品)のセットを、具体的なクラスを指定することなく生成するためのインターフェース(API)を提供するパターン
  • 部品の具体的な実装には注目せず、抽象のAPIに注目し、そのAPIだけを使って、部品のセットを組み立てていく
• 「ポリモーフィズム」を利用したパターン
  • 「工場」「部品」ともに抽象と具体のセットになっていて、利用者は抽象のAPIのみを使用する
  • どのConcreteFactoryを使うかを切り替えるだけで、生成される部品群を切り替えることができる

メリット・デメリット

メリット

• 具体的なクラスをクライアントから隠蔽する
• 利用する部品群の整合性を保つことができる

デメリット

• 必要なクラス数が多く、コードが必要以上に複雑になる可能性がある

用途

• 関連する部品群を決められた種別ごとに整合性を保って切り替えたい場合
  • 例) OSのGUI
    • mac,linux,windowsで表示されるブラウザのalertなどで表示されるボタンが異なる

デザインパターンの種類

生成に関するデザインパターン

例(Mermaid)

• AbstractFactory
  • インターフェースもしくは抽象クラス
  • 抽象的な部品であるAbstrctProductを生成するためのAPIを定義する
• AbstractProduct
  • インターフェースもしくは抽象クラス
  • 部品ごとのAPIを定義する
• ConcreteFactory
  • AbstractFactoryを継承(実装)する子クラス
  • 具体的な部品であるConcreteProductを返すように実装を行う
• ConcreteProduct
  • AbstractProductを継承(実装)する子クラス
  • ConcreteFactoryから返される具体的な部品

classDiagram
namespace Concrete {
	class ConcreteFactory {
		createProduct1()
		createProduct2()
		createProduct3()
	}
	class ConcreteProduct3 {
		performOne()
		performTwo()
	}
	class ConcreteProduct2 {
		doAlpha()
		doBeta()
	}
	class ConcreteProduct1 {
		executeA()
		executeB()
	}
	
}
namespace Abstract {

	class AbstractFactory {
		<<interface>>
		createProduct1()
		createProduct2()
		createProduct3()
	}
	class AbstractProduct3 {
		<<interface>>
		performOne()
		performTwo()
	}
	class AbstractProduct2 {
		<<interface>>
		doAlpha()
		doBeta()
	}
	class AbstractProduct1 {
		<<interface>>
		executeA()
		executeB()
	}
}
AbstractFactory --> AbstractProduct1 : Creates
AbstractFactory --> AbstractProduct2 : Creates
AbstractFactory --> AbstractProduct3 : Creates
ConcreteFactory --> ConcreteProduct1
ConcreteFactory --> ConcreteProduct2
ConcreteFactory --> ConcreteProduct3
ConcreteProduct3 ..> AbstractProduct3
ConcreteProduct2 ..> AbstractProduct2
ConcreteProduct1 ..> AbstractProduct1
ConcreteFactory ..> AbstractFactory