Since 1975

Simple Factory

というのが、デザインパターンとしてあるのですね。今日Twitter上のTLに流れてきて、気になってググってみたら、Strategic Choiceさんのブログに行き着きました。

Factory Methodとの違いは、Factoryを具象クラス一本に絞ったという感じでしょうか。

Factoryの具象クラスをインスタンスするのは誰？

さて本題。Factory Methodは、FactoryとProductの両方について、抽象層にインターフェースを設け、具象層に各インターフェースの具象クラスを置きます。ClientオブジェクトはFactoryのインターフェースを通して具象Productを生成し、インターフェースとして取得する形となります。

前から気になっていたのですが、誰かが具象Factoryを生成してあげる必要があります。ClientがFactoryをインスタンス化するのであれば、ClientはProductの実装への依存はなくせますが、依然factoryの実装には依存してしまいます。

じゃぁ、FactoryのためのFactoryが必要？

そのFactoryのためのFactory生成は誰が行うの？

と堂々巡りしてしまい、私の中では「いらない子」扱いのパターンでした。

DIコンテナさん登場

Factoryの具象クラスへの依存をどう解決すべきか分からず、もやっとしていたのですが、素直にDIコンテナさんに任せちゃえばいいんじゃないかなと、ここ最近気づきました。

しかし、DIコンテナの機能として、たいてい遅延実行をサポートしているので、遅延実行のための高階関数をFactory代わりにしてしまえる気がします。（使う側のClientはどんな形であれ依存が解決できればいいはずなので）

結局、Factory Methodいらなくね？と、現在進行形で「いらない子」になってるのでした。