avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Embedding and standardizing kernel parameter handling and discovery
Date Wed, 29 Oct 2003 09:24:33 GMT


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: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




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


Mime
View raw message