JavaBeans considered evil (was: Re: Embedding and standardizing kernel parameter handling and discovery)

[Leo Simons <le...@apache.org>]

Niclas Hedhman wrote:
 >>(2) removing most of the lifecycle
 >
 > That is IMHO a different debate.

yep. Which I was trying to point out, in fact :D

 > <quote
 > 
from="http://lists.codehaus.org/pipermail/picocontainer-dev/2003-October/001335.html" 

 > I am not saying that the Factory pattern is a bad pattern. But using it
 > merely to avoid having to pass in state through the constructor is not a
 > very good idea, especially not when the use of factories is optional
 > </quote>
 >
 > Maybe I misunderstand, but it is fairly easy to make Factories 
non-optional,
 > by private constructors. It is better to argue of "how to obtain the
 > factory".

The point is this: your average component in actuality depends on an 
*instance*, not on *a facility for creating an instance*.

 > <quote from="same doc">
 > /** @@Required */
 > <snip/>
 > Again, this just moves the problem: now a programmer
 > might forget to add the attribute.
 > </quote>
 >
 > This is also bad argument. <snip/> A much better argument is that the
 > use of special tools are required, beyond the standard compiler.

I think its a good argument, because forgetting a constructor arguments 
results in a red corner in the top right corner of the screen (with 
IDEA, anway), whereas forgetting an attribute does not even result in 
build failure.

The point is not that you need special tools (which is okay in and of 
itself), the point is that the need for special tools makes it easier to 
make mistakes.

<snip/>
 > Also, I would call the "DumbClient" "SmartClient"... ;o)

LOL!

 > Another thing I was thinking of;
 > Why is it inherently better that the Component holds a reference to a
 > resource, given at construction, than the Component has a way to 
lookup the
 > resource?

The key mind shift is that you move the lookup code outside of the 
component. Decouple.

 > IMHO, local caching (which it practically is) of various resources, 
also leads
 > to more "static" applications.

it leads to more "static" components. But you can make your application 
as dynamic as you want, for example by replacing a component (perhaps 
hot-swapping) with a differently configured one.

 > This may all be too philosophical for the avalon-dev list

nah :D

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org