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<snip/>
statements.
Dependencies are easy:
/** * @@Dependency() */ private final MailServer mailServer;
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
