The point about the Collections is only somewhat valid.
A great design prevents the caller from modifying a returned
collection if it should not be modified
(Collections.unmodifiableXXXX), and/or traps the Collection
modification operations to perform what is needed (to keep state in
sync).
Often creating a copy, modifying a value, and setting the copy, it
prohibitively expensive, and more fine grained access to the
Collection is required.
On Oct 16, 2007, at 6:37 PM, Charles Miller wrote:
On 16/10/2007, at 2:47 PM, robert engels wrote:
I am not debating that immutable objects makes concurrent
programming easier - it is just that immutable objects do not
model real world (domain) objects very well.
If I have an instance of the car, and I paint it RED, I don't get
a new instance of the Car,
The most efficient way to repaint the car would be:
Color.GREEN.setRGB(255, 0, 0); You don't do this, for obvious
reasons. :)
My point from the email you quoted, emphasis added: "As a general
design rule, objects _that represent values_ should be immutable."
My other point would be that there are a lot more things that
represent values (and that should be immutable until proven
otherwise) that programmers don't think about. My employer has a
standard coding test for new hires, and one bug that I'd say 90% of
candidates introduce during the course of the test is related to
modifying the contents of a collection when they should be creating
a new collection. Most applicants find the bug when I say "you
introduced a bug there, what is it?", but in the normal course of
programming that wouldn't happen.
C
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
