Niclas Hedhman wrote:
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...
Too philosophical?
No chance! There are pros and cons as you correctly point out.
Should a container/component contract deal with constructors? Probably - but with a very strong and consitent semantic model (which IMO means not passing services directly via a constructor, but supporting container/component artifacts [e.g. service manager, context, logger, etc.]). In fact - I personally use SomeComponent( Logger logger, SomeContext context ) all over the place. It really works well - but to turn this into a contract requires a defintion of SomeContext creation. If SomeContext is an interface, and DefaultSomeContext is a component - bingo everything works - but it could be more efficient if we attempted to located a factory service "[servicename]Factory" - i.e. SomeContextFactory - then handle resolution of a compoennt implementating the factory service.
Anyway - I'm still in general thinking mode on this subject.
Cheers, Steve.
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
