blog新米webエンジニアによる技術ブログ。第5章エンティティのメモが書けないまま第6章を終えてしまった。記憶の新しいうちに値オブジェクトの方のメモを書く。整数を許容してしまうが、数量にマイナスはない。)値オブジェクトにすべきところをエンティティにしてしまいがちだが、値オブジェクトにすることで使いやすくテストしやすくなるので、積極的に利用すべき可能な限り、エンティティよりは値オブジェクトを使ってモデリングすべきだと聞いたら、驚くかもしれない。ドメインの概念をエンティティとしてモデリングしなければいけないとしても、そのエンティティの設計は、子エンティティのコンテナではなく値のコンテナとして組み立てるよう心がけるべきだ。このアドバイスは、単なる気まぐれによるものではない。値型は何かを計測したり定量化したり説明したりするときに使うもので、作成やテストがしやすいし、使うのも最適化するのも保守するのも楽だ。値オブジェクトを使用するかどうかの判断基準は以下あるモデル要素について、その属性しか関心の対象とならないのであれば、その要素を値オブジェクトとして分類すること。値オブジェクトに、自分が伝える属性の意味を表現させ、関係した機能を与えること。値オブジェクトを不変なものとして扱うこと。同一性を与えず、エンティティを維持するために必要となる複雑な設計を避けること。実装(著者は通常)値オブジェクトの初期化は2つのコンストラクタを用意する:状態の属性を設定するために必要なすべてのパラメータを受け取る、「プライマリ」コンストラクタ。属性の初期化にはprivateなセッターを用いる(自己委譲)既存の値をコピーして新しいコンストラクタを作るコピーコンストラクタ。実装)ググっても出てこなかった。実装)以下がストラテジパターンにあたるというのがよくわからなかった。なんかを見る限り、共通のインターフェースを用意してストラテジごとの実装は各クラスに分けて切替可能にする、とかのようだ。算出ロジックが1種類しかないから実装をべたっと書いてしまっているけど、別の算出方法が登場した際にはどっかにインターフェースだけ定義して実装とは分離することになるんだろうか。回に分けてなんとか読み終えた。節の、コンテキストをまたいだ場合にエンティティではなく値オブジェクトとして定義することで責務を少なめに抑える、というのがまだぴんと来ていない。いうものであるかは感じ取ることができてよかった。詳しく知りたくなったらこのあたり読めばいいんだろうか。