Yeah, I don't like it. What I love about the way the framework currently
works is that a component is still a stand-alone piece of software. It is
given reference to a ServiceManager and then it can put itself together
based on its needs. In my opinion, this way of doing things is more in line
with object-oriented thinking. The container should not have to know about
the component's internals. This is putting too much of a burden on the
container. A component should do what it does, and a container should do
what it does. When everything is doing what its supposed to do, then you
have a well-designed piece of software. Of course, defining the exact
responsibilities of the container and of the component is part of what we're
all about...
Jonathan Hawkes
----- Original Message -----
From: "Leo Sutic" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 17, 2003 11:59 AM
Subject: [RT] IoC type, well, something
> 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.
>
> 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.
>
> 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;
>
> Tells the container to set this field to a MailServer component.
>
> But configuration? Well, suppose we restricted ourselves to this:
>
> Each configurable field in a component implementation is either:
>
> + A primitive value (double, int, boolean, etc.)
>
> + A class with a (String) constructor.
>
> + A class with a (Configuration) constructor.
>
> + A class that in turn has configurable fields.
>
> Then we can map each configuration entry into a field:
>
> /**
> * @@Configuration ("@max-threads")
> */
> private final int maxThreads;
>
> /**
> * @@Configuration ("background-color")
> */
> private final Color backgroundColor;
>
> /**
> * @@Configuration ("foreground-color")
> */
> private final Color foregroundColor;
>
> class Color {
> /**
> * @@Configuration ("@red")
> */
> int red;
>
> /**
> * @@Configuration ("@green")
> */
> int green;
>
> /**
> * @@Configuration ("@blue")
> */
> int blue;
> }
>
> And then use a configuration like this:
>
> <component max-threads="8">
> <foreground-color red="255" green="255" blue="255"/>
> <background-color red="255" green="255" blue="255"/>
> </component>
>
> In short, this would allow us to move the setting of fields
> to the container. The container can access private fields via the
> AccessibleObject.setAccessible, provided that the container class
> has the required security permissions (which I assume it can be
> given - it is the only class that needs it).
>
> Thoughts?
>
> /LS
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
