corrected one of the misconceptions I've held, which is the difference
between an Entity and a Value Object. I used to think they were the
same thing, but that an Entity was just a more important class in the
domain model than a Value Object. But according to the book, if I
understood it correctly, the main difference is identity. For an
Entity, its identity is important, whereas for Value Objects, its
identity does not. Whether you use the same instance of a VO or two
different instances, it doesn't matter for as long as the value(s)
within the VO are the same. However, for an Entity, one instance of an
Entity is not interchangeable for another.
The example used for an Entity was TransactionHistory. Each Customer
has a TransactionHistory that cannot be exchanged for another instance
of TransactionHistory.
Address, on the other hand, is a Value Object. It usually doesn't
matter if one is using the same instance of an Address object or
different instances, for as long as the values (street, city, zip code,
etc) are the same.
Thanks, man. This one of the first hits, from Google, for "entity object vs value object" (minus double-quotes).
ReplyDeleteI've been looking for a concise way to see this, and this is exactly like what my friend described to me, only easier to understand. [I needed an example.]
It is a bit more complicated than that. Two distinct Java objects may represent the same entity sometimes. When using an object-relational mapper, you may have a detached entity from an earlier transaction. A new query against the database results in a new Java object being instantiated. This is conceptually the same entity (albeit possibly in a different state, as attributes may have changed between the two transactions).
ReplyDeleteThis show the real difference between entities and value objects: entities have an identity that is independent of their state - state may change, identity not. The identity of value objects IS their state.
thanks for the short and quick reference to the difference
ReplyDeleteI don't agree with you about the TransactionHistory is Entity, I think it's rather be the value object.
ReplyDeleteWhen you mention an Entity, you mention its identity so its uniqueness. The TransactionHistory is not unique in some context, ie, you may change the status of the customer to 'Accept', and then 'Decline' and then 'Accept' again in the same day. In this context, you will have 2 transaction history that both have all the same attributes for a customer. So its identity is not satisfied. In this case, the transaction history is the same as OrderLines of Order. So the TransactionHistory can not be the Entity, it rather be the value object.
I don't agree with you about the TransactionHistory is Entity, I think it's rather be the value object.
ReplyDeleteWhen you mention an Entity, you mention its identity so its uniqueness. The TransactionHistory is not unique in some context, ie, you may change the status of the customer to 'Accept', and then 'Decline' and then 'Accept' again in the same day. In this context, you will have 2 transaction history that both have all the same attributes for a customer. So its identity is not satisfied. In this case, the transaction history is the same as OrderLines of Order. So the TransactionHistory can not be the Entity, it rather be the value object.