help: composition, static factory method, immutability,...and beans

[javac]

for better or worse, my free time is consumed by two Java series books
from Sun:

Java Platform Performance, 2000, by Wilson and Kesselman
Effective Java, 2001, by Bloch

1.) opinions on these books? good/bad/mediocre/great/etc? are they
up to date, or out of date?

2.) please do check out my code at
http://www.geocities.com/cjavacjava/src/ comments welcome :)

3.) i'm very impressed with the idea(s) of using small immutable
classes for composition. it's massively simplified my efforts towards
a "sim" of a cat/dog ecosystem. is this a common technique? is it
"modern" and "trendy", or "old" and "tired"? or am i just scratching
the surface of how things are really done in java? (ignoring
smalltalk/c++/c#) are static factory's common?

4.) I presently have two classes, LifeForm and Location, and'll add a
"Driver" class. the idea is the driver class will hold the collection
(vector for now) of LifeForm objects, who'll wander around
independantly. maybe twice a second I'd like to get a LifeForm object
to make a call(?) to incrementX. I want each life form to move
totally independantly. good/bad idea? if ok, pls point me in the
direction to get started on that.

5.) if small, immutable classes truly give better performance and are
_easier_ to design/use/etc, then what's the big deal with beans?
seems a major contradiction.

thanks,

ja***@mail.com

[Dan Nuttle]

A bean is one thing, for one purpose; an immutable object is another, for
another purpose. Incidentally, there's nothing that says a bean can't be
immutable, but they often aren't. But just because a class (bean) has
getters and setters, that doesn't means it's mutable. For instance, a bean
that accepts only Strings in its getters is still immutable, because the
Strings themselves are immutable. And even if the object stored is mutable,
the bean can still be made mutable:

public setMyProperty(MyObject o)
{
_o = new MyObject(o);
}

I.e., we're storing a new copy of the object passed in, rather than a
reference to the one passed in.

In general, immutability is always good unless there's an overriding reason
not to use it. In other words, always prefer it, and make any given
situation "prove" that mutability is necessary.

Joshua Bloch's "Effective Java" talks about this stuff at length. I highly
recommend it. I'm only scratching the surface here, and he understands and
explains this stuff much better than I do.

As far as static factory methods, again, they make sense in certain
situations. I'm not sure if you're talking about the GoF static factory
method pattern, or just using static factory methods in place of
constructors.

An instance of the GoF pattern is iterator(). It meets three critera: 1)
It provides an instance of an object. 2) It provides a type, rather than a
specific implementation. (You don't know what specific implementation of
the Iterator interface is being returned). 3) It's used by several classes.

For Java patterns I recommend Steven Metsker's "Design Patterns Java
Workbook." It covers all of the GoF patterns in Java. And the author is
more than willing to respond to emails with questions.

You might be talking about simply using a static method to provide an
instance of a class, rather than constructors. For instance, you could
declare a class that has no public constructor, but has a getInstance()
method that returns an instance of the class. It might be a singleton, or
it might not; it doesn't matter to the client. This isn't a GoF pattern
usage, but it can be a very useful technique, avoiding the inherent problems
involved with constructors, but it has its own drawbacks. Again, Bloch
covers this topic in great detail and with wonderful clarity and relevance.

The most important thing I glean from your post is that you are thinking
critically about OO concepts in Java, and you obviously enjoy doing it, and
sharing your thoughts with other OO developers. That's always good.

[Ryan Stewart]

"Dan Nuttle" <d_******@hotmail.com> wrote in message
news:a9****************@newsread2.news.atl.earthli nk.net...

A bean is one thing, for one purpose; an immutable object is another, for
another purpose. Incidentally, there's nothing that says a bean can't be
immutable, but they often aren't. But just because a class (bean) has
getters and setters, that doesn't means it's mutable. For instance, a bean that accepts only Strings in its getters is still immutable, because the
Strings themselves are immutable.

That's not accurate. If the bean has setters, it is mutable. Mutability
refers to the "changability" of the contents of an object. If a bean is
composed of three strings and has a setter for each (or even just one), can
the contents of the bean change? Yes, so it is mutable.

To the OP: You'd be better off posting to comp.lang.java.help in the future.
This group is not carried by all news servers, so many people don't see
posts here.