AbstractFactoryパターンをenumで生成するメリット

投稿日：2020年7月12日更新日：2021年5月5日

AbstractFactoryパターンの説明には、実行時引数に文字列を渡したり、フラグでif-else判定する例をよく見かける。

しかし、どんなFactoryが生成可能を知らない担当者がFactoryを利用する場合はどうするのだろうか？
自分でコードを調べるか、Factory側のコード担当者に確認するかのどちらかになる。

Factory側の担当者は、クライアントのコード担当者の為であろうと、
自分にいちいち聞きに来た時に答えるのが面倒だという理由であろうと、
『Enumにしておけば何を生成できるかを明白に示せる』ということを知っておいてもらいたい。

よく見るFactroy生成方法

クラス名を文字列で渡して判定するコード例

・指定する文字列が異なることは無いと言えるか？
・大文字小文字を間違わないということはあり得るか？
・そもそも、存在しないFactoryを呼び出すようなことにはならないか？
文字列を指定するコードでは、上記の問題が起こりうる。

フラグで生成するFactoryを判定する例

これも文字列の場合と同じ問題を抱えている。
この場合、予期しないFactoryが生成される可能性がある。
つまり、0以外はすべてFactroyYが生成されるが、それが想定通りの仕様であることを保証しないということだ。

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に存在するFactroyしか生成できないため、誤ったFactoryを生成することが無い。
・チーム開発の場合、生成可能なFactoryクラスがなんであるかをクライアント側のコード担当者が知っている必要がない。
　Factoryクラスが不足しているなら、Factory側を担当しているプログラマに依頼すればよいだけとなる。
・Factoryの追加が簡単。
　Enumに必要なFactoryクラスを追加するだけなので、if文を修正するようなことは不要である。

自分一人だけでプログラムを書いていれば、このようなことは考えなくてもよいと思うが、
チームで仕事をし、かつモジュールを分割して担当しているのであれば、
このようなに考えることで変更容易性を高め、モジュール化を円滑にできる。