avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [RT] IoC type, well, something
Date Mon, 17 Nov 2003 19:46:14 GMT
Leo Sutic wrote:
> I read Leo Simons story of the little component that could.
> 
> The basic idea was...
> 
>    ...that everything should be passed in the 
>       constructor
> 
>    ...that all components are what we would call 
>       ThreadSafe/Singleton, i.e. you get one reference
>       and can keep it.

actually, the idea at that point was that you may be receiving a proxy 
which implements the lifestyle under the covers...hot swapping is still 
possible even if you keep the reference.....except that if you make 
things event-based, the need for pooling goes away again.....damn, I 
really need to write a lot of thoughts down :D

> Now, suppose I have a component with about 20 parameters and
> four other dependencies.
> 
> I get a constructor with 24 parameters. And the constructor itself
> will be 24 lines of:
> 
>     this.m_variable = variable;
> 
> I hate it when that happens.

re-decompose, encapsulate! Arrive at the concept of the strongly typed, 
value-verifying config bean :D

I would also add that with 24 parameters, what we're coming from is 24 
lines of

   m_variable = m_configuration.getChild( VARIABLE_KEY ).getValue();

> So I returned to thinking about how a container can set the values 
> and start up a component without having to code all those assignment
> statements.
> 
> Dependencies are easy:
> 
>     /**
>      * @@Dependency()
>      */
>     private final MailServer mailServer;
<snip/>
> Thoughts?

My gut feeling tells me: BAD BAD BAD BAD. On the one hand, there's

   The Principle Of The Lazy Programmer

and it seems like such a nice idea. While we save not a single line of 
code (still need the /** @@Dependency() */ line for each field, we do 
keep the 'metadata' ("This field is a dependency and hence it is (set 
through the constructor|set by the container automagically") closer to 
the field declaration.

On the other hand, there's

   The Principle Of Too Much Magic

we're introducing a lot of magic:

  * reflection
  * a new pseudo-language (rich javadoc attributes)
  * a new metadata format (javadoc storage in jar)
  * a new developer tool (compile pseudo-language into metadata format)

these are pretty big 'sacrifices'. The code is probably slower, unit 
testing will probably require special pseudocontainer tools, there's a 
learning curve to learn the tools and formats, specifications to write, 
documentation to maintain....

...meanwhile, and this is the big alarm bell ringing in my head, our 
component isn't really a POJO anymore. Unless we still keep the really 
big constructor (and that means not 24 but 48 lines of parameter 
setting), there's no practical way to use it outside of a container 
(unless you want tons of lines full of reflection code). Bye-bye reuse.

I could babble on a little more, but I think the point's been made. Yet 
the temptation of laziness and elegance remains....I am somewhat hoping 
for you to dissolve my reasoning :D

- LSD



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


Mime
View raw message