前回のふりかえり

第6章

→　ファクトリの出番

ファクトリ：他のオブジェクトの生成を責務とするもの
- 複雑なオブジェクトや集約のインスタンス生成をファクトリに任せる。
  - ファクトリはドメイン層の一部となる。
- ファクトリが複雑な組み立て処理をカプセル化する。
- 集約全体をひとまとまりとして生成する。(ファクトリは集約単位で生成される？

一般的に...

上記を踏まえると、ファクトリメソッドは下記の場所に生成するのがよい

1. 集約のルートエンティティ

ファクトリで生成されたオブジェクトは、ルートエンティティに参照を保持される

2. 他のオブジェクトの生成に密接に関わるオブジェクト

オブジェクト生成はするが、そのクラスは生成物を所有しない

3. 独立したファクトリ

ファクトリを所属させるのは、生成物にたいして自然で密接に関係するオブジェクトにするべき
- そのようなオブジェクト(場所)が無い場合は、独立したファクトリオブジェクト(or サービス)を作る
- ただし、アクセスは集約の内部に制限する

※ だが、対象が単純であればコンストラクタで事足りることもある

構造が単純なオブジェクトにまでファクトリを使うと、逆にオブジェクトが不明瞭になる

エンティティファクトリ
- 有効な集約を受け取るだけの、本質的な属性だけを受け取る
- エンティティの同一性を担保するための識別子について
  - 識別子がユーザ指定のものなら、その値はファクトリの引数で渡す
  - プログラムが識別子を用意するなら、それはファクトリで制御する
値オブジェクトファクトリ
- 生成物を完全に記述する(生成後に値が変わることはないようにする)
再構成のためのファクトリ
- データベースの値からオブジェクトを再構築するためのファクトリ
  - 再構成のためのエンティティファクトリでは、IDは既に割り当てられたものを使う
  - 値オブジェクトファクトリでも不変条件を制御するが、違反した時の処理は柔軟性が必要。(生成時の様に処理を中止するのが適切でない場合もある)

※ データベースを元に作ったオブジェクトは厳密には「生成物」ではない。ライフサイクル中期のオブジェクト

オブジェクトの組み立て操作をクライアントに任せると、ドメイン層の知識がクライアントに流出するというのはよくわかった。ただ、ファクトリの具体的な姿がよくわかっていないせいかちょっとしっくりきていない。
ファクトリメソッドを作っても、引数が複数になるとクライアント側にもある程度組み立て作業(引数で渡すオブジェクトを用意する処理)は残ってしまうのではという疑問を抱いたけど...そもそもそのような事態になるのがおかしい？