I described Value Object as a small object such as a Money or date range object. Their key property is that they follow value semantics rather than reference semantics.
You can usually tell them because their notion of equality isn't based on identity, instead two value objects are equal if all their fields are equal. Although all fields are equal, you don't need to compare all fields if a subset is unique - for example currency codes for currency objects are enough to test equality.
A general heuristic is that value objects should be entirely immutable. If you want to change a value object you should replace the object with a new one and not be allowed to update the values of the value object itself -
Value ObjectをMoneyや日付の範囲といった小さな対象として、描写しました。それらの重要な特性は、関係意味論よりも価値意味論につき従うということです。
平等の観念はアイデンティティーに基づかず、貨幣の対象についてその指標が平等性を確かめるのに十分であるように、代わりに2つの価値対象は同じ条件下であれば、平等となるため、たいていはそのことを伝えることができます。
一般的な発見的教授法では、価値対象が完全に普遍であるべきです。価値対象を変えたいのであれば、対象を新しいものにし、価値対象自体の価値を更新すべきではありません。
updatable value objects lead to aliasing problems.
Early J2EE literature used the term value object to describe a different notion, what I call a Data Transfer Object. They have since changed their usage and use the term Transfer Object instead.
***
When you're working with a remote interface, such as Remote Facade, each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program - indeed, it's often impossible with languages such as Java that return only a single value.
更新可能な価値対象は、別名の問題を引き起こす。
初期のJ2EEの文学は、Data Transfer Objectと呼んでいる異なる観念を描写すべく、価値対象という言葉を使用した。それから使用方法が変わり、代わりにTransfer Objectという言葉が用いられた。
***
Remote Facadeといったリモート・インターフェースを使っているなら、どちらの呼び方も値打ちがある。結果として、呼び名の数を減らす必要があり、それぞれでたくさんのデータを移送する必要があるということだ。これをするには、たくさんのパラメーターが必要だ。しかし、これはしばしばプログラミングには適さない。実際、1つの価値しか呼びこまないJavaのような言語にはよく不可能となる。
