AbstractFactoryパターンの説明には、実行時引数に文字列を渡したり、フラグでif-else判定する例をよく見かけます。
個人開発では自分がすべてを把握しているため気にならないかもしれません。
しかし、チーム開発で他チームにモジュールとして提供している場合、
Factoryの提供を受けたチームが生成可能なFactoryを知るにはどうするのか？
方法としては、自分でコードを調べるか、Factory側のコード担当者に確認するかのどちらかになると思います。
Factory側の担当者は、クライアントのコード担当者の為であろうと、
自分にいちいち聞きに来た時に答えるのが面倒だという理由であろうと、
**『Enumにしておけば何を生成できるかを明白に示せる』**ということを知っておいてもらいたい。
よく見るFactroy生成方法
クラス名を文字列で渡して判定するコード例
これには以下の問題を抱えていると考えています。
・指定する文字列が異なることは無いと言えるか？
・大文字小文字を間違わないということはあり得るか？
・そもそも、存在しないFactoryを呼び出すようなことにはならないか？
フラグで生成するFactoryを判定する例
これも文字列の場合と同じ問題を抱えていると考えています。
またこの判定条件だと、0以外はすべてFactroyYが生成されるということになり、
予期せずFactoryYが生成される可能性を含んでいます。
Enumを使う例
Enumを使って実装すると、生成するFactroyを明示的に示し、かつ存在しないFactoryを生成することは無くなります。
※以降のコードは、TECH SCOREのAbstractFactoryパターンを私が独自に改良したものです。
TECH SCOREとは一切関係ないことはお含みおきください。
8. AbstractFactory パターン
Use.java(クライアント)
EnumであるHotpotTypeでRecipe（Factoryクラス）を指定して生成しています。
HotpotType.java(Factoryを生成するEnum)
生成可能なFactoryをここで定義しておきます。 Sukiyaki（すき焼き）を指定すれば、SukiyakiRecipeを生成するという具合です。
Recipe.java(Factoryクラス)
Factoryの生成はHotpotTypeに委譲しているため、抽象的な実装のみに専念できます。
Enumで生成するメリット
・Enumに存在するFactroyしか生成できないため、誤ったFactoryを生成することが無い。
・チーム開発の場合、生成可能なFactoryクラスがなんであるかをクライアント側のコード担当者が知っている必要がない。
Factoryクラスが不足しているなら、Factory側を担当しているプログラマに依頼すればよいだけとなる。
・Factoryの追加が簡単。
Enumに必要なFactoryクラスを追加するだけなので、if文を修正するようなことは不要となる。
自分一人だけでプログラムを書いていれば、このようなことは考えなくてもよいと思うが、
チームで仕事をし、かつモジュールを分割して担当しているのであれば、
このようなに考えることで変更容易性を高め、モジュール化を円滑にできる。
クラス図
