On Tuesday 28 October 2003 19:00, Leo Simons wrote: > Note that you're doing two things: > > (1) using strong typing
I like strong typing (my keyboard does not like it so much, it breaks often ;o) ) ... > (2) removing most of the lifecycle That is IMHO a different debate. Many of my components needs a dual-staged start, creation separate from "start()". I like lifecycles, but believe that they should be more "pluggable". > http://lists.codehaus.org/pipermail/picocontainer-dev/2003-October/001335.h >tml and version 1: > http://lists.codehaus.org/pipermail/picocontainer-dev/2003-October/001313.h >tml <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". <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. The attribute is created by the programmer who knows the contract. I could as easily argue that your "put in constructor" just moves the problem, now the programmer have to remember to create an argument-contructor. A much better argument is that the use of special tools are required, beyond the standard compiler. In the other doc, about the FakeBank, it is not a good example, as it will throw a NullPointerException at doAttemptRobbery() if line //1 is forgotten, at "if( manager.robberyDisabled() )". Also, I would call the "DumbClient" "SmartClient"... ;o) 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? IMHO, local caching (which it practically is) of various resources, also leads to more "static" applications. This may all be too philosophical for the avalon-dev list, but... Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
