ColdFusion and what is a ValueObject as Flex developers seem to not know
Tags: General, ColdFusion 8, Coldfusion, Flex, ColdFusion 9, Coldbox
It seems that somewhere some how someone quoted in the ColdFusion world, what a Value Object actually is by their definition. Since then the term has taken of in the Flex world like wild fire, and yet every time I ask these people what they think a Value Object is, they actually get it so wrong that it is not funny.
Nine times out of ten when these people are asked their answer are actually describing what we call Transfer Objects, and yet how does something like this exist and yet be so far wrong in the Flex world?
So what is a Value Object?
Examples of Value Objects are things like numbers, boolean and strings. Where in an Object Orientated world we have an object that's sole purpose is to actually carry a value. Although ColdFusion and I am almost 100% sure Flex won't fall into this category, but Value Objects are suppose to also override the equals method.
And here is an example of a Point Value Object in C++, it sole purpose is to hold an X & Y value.
class Point {
public: Point( int x, int y ):
_x(x), _y(y) {}
int getX() const { return _x; }
int getY() const { return _y; }
void setX( int x ) { _x = x; }
void setY( int y ) { _y = y; }
private:
int _x;
int _y;
}
public: Point( int x, int y ):
_x(x), _y(y) {}
int getX() const { return _x; }
int getY() const { return _y; }
void setX( int x ) { _x = x; }
void setY( int y ) { _y = y; }
private:
int _x;
int _y;
}
So if this is what a Value Object actually is, then what is the object that these Flex Developers are referring too? They are actually called Transfer Objects, as defined in by Sun in 2002 definition of Transfer Object.
I hope this starts to clear things up, because I am getting a little tired of hearing the term Value Object used when that is not what these people are actually talking about.
ColdFusion and what is a ValueObject as Flex developers seem to not know - http://cfbloggers.org/?c=45633
Nov 8, 2010
-
Actually, the pattern was known as "Value Object" (VO) for years, Andrew (<a href="http://java.sun.com/j2ee/patterns/ValueObject.html...">http://java.sun.com/j2ee/patterns/ValueObject.html...</a>).
Sun later decided to change the name to Transfer Object (TO), while Fowler calls it Data Transfer Object (DTO) in Patterns of Enterprise Application Architecture.
They all refer to the same thing, and while VO may be technically incorrect if one listens to Sun, in practice VO == TO == DTO. If someone talks about any of these, everyone else knows what they mean. In over 10 years, I have *never once* heard anyone talk about VO in reference to Sun's modified definition.
As long as the intent is clear, people will continue to use any of these names. Sun fostered this confusion themselves, so you're better off just accepting that there are multiple labels for this pattern instead of belittling those who choose to use the original definition.# Posted By Brian Kotek | 11/8/10 9:48 PM -
@Brian, while you are correct Sun did rename it to TO and with very good reason. Outside of Sun VO's meant an entirely different thing, so in practice and in theory VO != TO
Sorry I can't accept that, because VO in its true definition was around long before Sun even brought up their VO problem.
# Posted By Andrew Scott | 11/8/10 10:35 PM -
Can I also add that it was changed in 2002, Flex users started using it around what year? A good 5 years after sun changed it, but Value objects in C++ has been very clear right from the word go.
# Posted By Andrew Scott | 11/9/10 12:07 AM -
The real point is that you're saying people "don't know what they're talking about", when the link I posted earlier clearly shows that Sun called this Value Object for YEARS. If you Google, look at Wikipedia, or even look at Sun's current definition for TO, they ALL mention that this was also known as Value Object.
You're certainly free to use the term TO or DTO if you choose. But your tone makes it sound like people calling it VO are pulling it out of nowhere, which is simply not the case. This was and is a widely adopted term, since Core JEE Patterns was the most influential book on patterns since the GoF Design Patterns book.
Would it be nice if people standardized on DTO as the name? Sure, and I personally use the name DTO. But are you justified in bashing someone who uses the widely accepted name VO? Certainly not.
If you care to listen to a little constructive criticism: You've got to realize that you can make your point without being nasty about it.
# Posted By Brian Kotek | 11/9/10 12:15 AM -
Andrew,
While I agree that saying "VO" when referring to "objects that carry snapshots of state between tiers" is incorrect, nitpicking definitions of design patterns is completely missing the point of design patterns.
Design patterns are a tool for communications. Their definitions are constantly evolving. Especially in the RIA world, it's common for the same class to function as a VO and DTO. Given the classic-ish "container of state that can be compared by value via overriding equality" definition you reference, it'd even be common for a client-side BO to also function as a VO, all depending on the situation.
If the intent is communicated, all is good. If the intent is miscommunicated widely enough, the definition is often rewritten - which can have consequences both good and bad.
# Posted By Joe Rinehart | 11/9/10 9:55 AM -
So what people are saying is that it is ok to come along a few years later, and change the definition of a Value Object to suit their needs?
Begs the question why do we adopt patterns in the first place, knowing that its meaning will be taken incorrectly down the track by another language like Flex has done.
I am sorry but it is very clear what a Value Object is, and its definition hasn't changed since the days it was introduced in C++. Yes Java got it wrong, to the point that they changed the definition. Now Flex is making the same mistake, so how long will it be before that is changed?
That would be like me saying that a steering wheel is no longer a steering wheel in a car, but I can now call it Turning Object.# Posted By Andrew Scott | 11/9/10 4:59 PM -
I thought I would share this.</p><p>From Martin Fowler.
The confusion from the Core J2EE book caused a lot of frustration. It's a shame to see the same mix-up has infected the flash community.
# Posted By Andrew Scott | 11/9/10 7:28 PM -
I just don't see how you can keep missing the real point here, which is that you can make your case that VO is an outdated definition without being arrogant and abusive about it. I guess it's hopeless...
By the way, your subscribe option is broken.# Posted By Brian Kotek | 11/9/10 10:15 PM -
But it is not outdated, it only becomes outdated in the Flex world becuase these people chose to break what the broder world has come to accept.
Flex came well after Sun corrected their notes, and documentation. And as Martin also pointed out to me in an email, is that the Flex world is keeping the confusion alive because now we have something that means two distinct things, and Martin also states that the broader world has gone DTO.
So I will stand by the fact that I have used VO's since before Flex was ever a twinkle in Adobe's eyes. And it means what it means and the definition of that meaning is actually very clear.
If Flex developers wish to continue down this path and make if more confusing by adopting a second meaning for it then fine, but that means that they are going to be a minority.
Imagine yourself coming over to Flex for the first time, and hearing what a VO is in that little world and going wait a minute that is not what a VO is at all.
you can't just rewrite the rules to suit yourself, and that is what the Flex community has done here. Nothing more nothing less, and when you have something that can mean two distinct things as Martin points out then you are opening a can of worms, and a hell of a lot of confusion.
And that is what I will not change, it is bad enough trying to learn something and then hearing something that you know is not right.
And yes I am aware that the subscribe is broken, I have an older blogCFC mixed with some newer code and updating blogCFC has become a pain. I am about to re-release a better version shortly that fixes a lot of these problems.
# Posted By Andrew Scott | 11/9/10 10:39 PM
TweetBacks