まとめ

別名

Kit

AbstractFactory
- AbstractProductを返却するメソッドのインタフェースを定義
- メソッドに実装を持たせてもいい
  その場合はConcreteFactoryで適宜overrideする
- ぶっちゃけAbstractじゃなくてもいい
ConcreteFactory
- AbstractFactoryの実装
- シグネチャ的にはAbstractProductを返す
  - 利用側はConcreteProductを意識しない
- もちろん生成してreturnするのはConcreteProduct
AbstractProduct
- 生成するオブジェクトのクラスを抽象化したクラス
- ScrollBarとかButtonとか
- ファクトリ利用側はこれのみ意識する
ConcreteProduct
- 生成するオブジェクトのクラス
- MotifScrollBarとかPMButtonとか
  - MotifとかPresentationManagerとかを利用側は意識しない
  - MotifButtonはMotifScrollBarと一緒に使う、といった条件を
    利用側に意識させない
Family
- クラスではない
- MotifScrollBar,MotifButton など、一緒に使うべきProduct一式

ファクトリ利用側に、Productの具体的なクラスを意識させない
- 利用側コードからMotifとかPMとかいう文字列が消える
Familyの切り替えが楽
- Motif一式をPM一式にしたり
  - 利用側で直接newとかするとこうはいかない
一貫性が保たれる
- コピペ修正漏れでMotif ScrollBar上でPM Buttonを使ってしまう、ということがなくなる
Productの種類を増やすのは大変
- AbstractFactoryのインタフェースの追加変更を伴う
  - 各ConcreteFactoryも影響を受ける

AbstractFactory.CreateScrollBar(), AbstractFactory.CreateButton()とかを定義して、ConcreteFactoryで実装|overrideする
- この方法だと、FamilyごとにConcreteFactoryを作る必要がある
  - Family1とFamily2の差分がProduct一種類だけでも、である
  - Familyの数が多いときつい

型安全性とのトレードオフ
AbstractWidget AbstractFactory.Create('button') という感じにする
- ScrollBar, Button等を一緒くたに扱うクラスが必要(Widget)
- 危険なダウンキャストを伴う (Widget => Button)

上記「Productが増えても大変にならない実装」は型安全でない
ファクトリ内で自身の別のメソッドを呼んで作ったAbstractProductは、
同じFamilyのものであることが保証されるので安全にダウンキャストできる
- PMFactory.CreateWindow()の中でPMFactory.CreateButton()を呼び、Buttonを作ったとする
- これは安全にPMButtonにダウンキャストできる