views:

51

answers:

2

I am a programmer with a .NET / PHP background.

I recently reviewed a video training on Flashbuilder 4 / ActionScript. One of the videos in the video training is named "Creating a Data Model with a Value Object". I mentioned that "value object" was an unfamiliar term to me and didn't really know if he meant by it "model" or not and it was a bit confusing since I can only understand it as a "model" yet the title suggests that we are creating a model with a value object, suggesting they are two different entities.

The trainer said that he was told this was a fairly common term in Java, also sometimes referred to as a "transfer object". In fact, the Wikipedia page for "value object" redirects to "Data transfer object", and stackoverflow questions like this one mention that a "value object" might also be a "mapped object in Java".

What is the etymology of this term and how does it relate to other data-model-related terms? Does it come from the Java world and did it at some point go out of wide-spread use?

A: 

The term seems to be overloaded in different contexts. Misko Hevery describes the term as I interpret it:

An Injectable class can ask for other Injectables in its constructor. (Sometimes I refer to Injectables as Service Objects, but that term is overloaded.) [...] Here are some examples of classes I would expect to get from my DI framework: CreditCardProcessor, MusicPlayer, MailSender, OfflineQueue.

Similarly Newables can ask for other Newables in their constructor, but not for Injectables (Sometimes I refer to Newables as Value Object, but again, the term is overloaded). Some examples of Newables are: Email, MailMessage, User, CreditCard, Song. If you keep this distinctions your code will be easy to test and work with. If you break this rule your code will be hard to test.

Another description that I would agree with is the one at http://c2.com/cgi/wiki?ValueObject

Examples of value objects are things like numbers, dates, monies and strings. Usually, they are small objects which are used quite widely. Their identity is based on their state rather than on their object identity. This way, you can have multiple copies of the same conceptual value object.

So I can have multiple copies of an object that represents the date 16 Jan 1998. Any of these copies will be equal to each other. For a small object such as this, it is often easier to create new ones and move them around rather than rely on a single object to represent the date.

A value object should always override .equals() in Java (or = in Smalltalk). (Remember to override .hashCode() as well.)

aioobe
A: 

I was at Jazoon 2010 where Kevlin Henney gave a talk on 'the Value of Objects' - I highly recommend watching or reading the presentation (which covers value objects). There's too much content for me to easily summerise, but my interpretation would be:

Value Object

An object representing information in a model. It does not have identity and is immutable. For example, the date 13 October 2010 can be represented as a value object. It does not have an identity and the 13 October 2010 is always the 13 October 2010 - it never changes.

I also recommend taking the opportunity to listen to Kevlin in person if you get the chance. I find him to be damn good speaker.

You may also want to check out Eric Evan's Domain Driven Design book as I believe this is the modern-day source of the concept of value objects in the Java world.

hbunny
I don't think Value Objects are always immutable.
keuleJ
Don't confuse implementation with the semantics. Java's Calendar class is mutable - you can create a value of 13 October 2010 and then you can change it to say it's now November - the language allows it, but to me it's wrong. It's like saying I'm changing the value 42 to 43.
hbunny
@hbunny: Calendar is not a value object according to *any* definition - it exists to manipulate dates, not to store them (that's what Date is for, and in that case being mutable is clearly wrong).
Michael Borgwardt