ファクトリとは
何かを作るものです。
ファクトリが必要な理由
エリック・エヴァンスのドメイン駆動設計 No.3258(Kindle) 「第6章 ドメインオブジェクトのライフサイクル」に以下のように書かれています。
オブジェクトの生成は、それ自体が主要な操作になり得るが、 複雑な組み立て操作は、生成されるオブジェクトの責務には合わない。 そういう責務を組み合わせてしまうと、 理解しにくく不格好な設計が作り出されるかもしれない。 そうかといって、クライアントに直接構築させると、 クライアントの設計を混乱させ、組み立てられるオブジェクトや 集約のカプセル化にも違反する上に、 生成されるオブジェクトの実装と、クライアントが過度に結合することになる。
複雑なオブジェクトと集約のインスタンスを生成する責務を、 別のオブジェクトに移すこと。その別のオブジェクトは、 それ自体はドメインモデルにおいて何の責務も負っていないかもしれないが、 それでもドメイン設計の一部であることに変わりはない。 複雑な組み立てをすべてカプセル化するインタフェースを提供すること。 その際に、インスタンス化されるオブジェクトの具象クラスを、 クライアントが参照しなくてもよいようにすること。 集約全体をひとまとまりとして生成し、その不変条件を強制すること。
自分なりにまとめると、次のようになります。
- ドメインオブジェクトに複雑な構築をさせると、わかりにくくなる。
- 呼び出し元に複雑な構築をさせると、密結合になる。
- こっちの方がより悪いです。
デザインパターン
以下の3つが、使われるデザインパターンとして挙げられています。
- Factory Methodパターン
- Builderパターン
- Abstract Factoryパターン
ただ、自分は、デザインパターンを理解するのはあまり意味が無いと思います。 なぜなら、実情に合っていないからです。 例えば、Builderパターンはよく使われますが、 GoFのBuilderパターンで出てくるDirectorはめったに登場しません1。
参考文献
-
というより見たことありません。。。 ↩︎