

Immutability and Value Objects - sudhirj
http://hangar.runway7.net/immutability-and-value-objects

======
ExpiredLink
Values are stateless and immutable, objects are stateful and mutable. Strictly
speaking, the term 'Value Object' is an oxymoron. Unfortunately, in Java you
can define values only in terms of classes and objects which leads to
continuous confusion. The distinction between values and objects remains
unclear for most Java developers.

~~~
bunderbunder
In the first research forays into what became OOP, objects were conceived of
as being immutable by definition. That quickly went by the wayside as it ran
up against a number of practical hurdles. But even then, in earlier true OOP
languages such as Smalltalk there was simply no distinction between values and
objects. In classic OOP, everything is an object, period.

Later on, languages such as C++ and Java muddied the waters (imo) by throwing
their own distinctive interpretations of what it means to be object-oriented
into the ring. One of these 'innovations' was the idea that values and objects
are somehow distinct. This idea has nothing to do with OOP orthodoxy and,
everything to do with C++ maintaining a strong semantic distinction between
the procedural type system it inherited from C and the object-oriented type
system it introduced.

Java simply followed C++'s lead on that front, albeit unnecessarily since Java
lacks the characteristic (linking with C binaries) that motivated that feature
in C++. Thus, there was an incredibly popular language which advertised itself
as object-oriented, but featured wooly non-standard (for OOP) semantics for no
apparent reason.

Which naturally invites some retconning. Hence the idea that the concept of
objects is anything but purely orthogonal to the distinction between value and
reference semantics. Without such stories, one is stuck with the more
historical story that a central, but often obnoxious and confusing (for
learners, at least) feature of the two most popular languages in current usage
is simply a hack in one case, and a foolish consistency in the other.

------
tinus
More nitpicky feedback:

    
    
       assertEquals(oneMeter, tenCentimeters);
    

Of course the code is not wrong per se, it will simply throw an exception, but
it still made me frown. I wonder if you really meant to write this.

Anyhow, this is a great article! I value the clear wording.

------
zeeed
thanks for the posting.

Quick feedback: you use "lX" as a variable name. That makes the code barely
readable, because the letter l looks VERY similar to the number 1 in most
systems.

It might sound nitpicky but it does distract from the article.

~~~
sudhirj
Thanks for the tip :) ... will make an update.

