エンティティ(Entities)
多くのオブジェクトは、本質的に、その属性によってではなく、連続性と同一性(identity)によって定義される(第二部 第五章より)
ここ改めて読むとすごいわかりずらいですね。。。
同一性
注文の例で言えば、注文完了しても、顧客の元に配送が完了しても、キャンセルされても、それが同じ注文であれば、それを認識できなければいけない。
5分後に別の商品の注文があれば、先の注文と、その注文は区別されなければならない。
顧客の例で言えば、住所が変わっても、配送先が変わっても、姓が変わっても、さらには退会しても、同じ顧客であることを認識できなければいけない。さらにはサポートに問い合わせがあれば、電話の先の声の主と一致していることを確認できなければいけない。
連続性
注文の例で言えば、注文完了したり、配送完了したりと状態が変わっていくという、連続性がある。それは、アプリケーション内だけでなく、注文完了したら一旦、注文はRDBに送られ永続化される。その後、キャンセルのためにRDBから抽出されても、同じ注文であることを確認できる必要がある。
また、そういった注文の状態の変化や、他の属性の変化も、効果的に追跡できるようにする必要がある。
「属性によってではなく」とは
注文の例で言えば、購入された商品や配送先の情報、配達状況など、その属性は変化する。
顧客の例でも、住所や姓、名前自体も変わるかもしれない。メールアドレスや電話番号も変わるかもしれないが、変わっても同じ顧客だと認識されなければいけない。
そういう意味で、エンティティは属性ではなく、同一性・連続性に注目して定義する必要がある。
エンティティのクラス定義、責務、属性、および関連は、エンティティの持つ特定の属性ではなく、それが何者であるかを中心にすえるべきだ。(第二部 第五章より)
エンティティは何でないか
javaのequalsはエンティティの同一性ではない
javaのequalsは標準では、同じメモリ上にあるオブジェクトの比較に用いられるもの。
例えば、キャンセルしたいと連絡があった注文のオブジェクトと、確認のためRDBから取得した注文のオブジェクトは同じ注文なのでイコールでなければいけないが、標準のjavaのequalsで比較してもtrueとはならない。
金額とか、住所とか姓名もエンティティではない
金額そのもの、1,000円とか1,200円とかは連続性（そもそも状態が変化しない）も同一性も関係ないのでエンティティではない。
住所とか、姓名も同様。
明日はどうこれをモデリングするかというところを読みます。