On Fri, 20 Dec 2002 02:30 pm, Peter Donald wrote:
> On Fri, 20 Dec 2002 12:56, Adam Murdoch wrote:
> > Goodness. I just want to get the stuff I need for my component. Why is
> > it so hard? Why do I need to know all this stuff? Why isn't there a
> > single method that gives me what I need? What benefit do I get out of
> > all these methods and contracts?
>
> The same benefits you get when you asked this last time scalability and
> flexibility.
Different questions. Last time it was 'what is context good for?'. Now it's
'why deliver resources using more than one lifecycle method?'.
> Some component styles don't implement Contextualizable or
> Serviceable/Composable or Configurable/Parameterizable or whatever.
But this isn't a benefit. It's flexibility for it's own sake.
> Others
> do different things at different stages (ie some containers have replaced
> Comopsable/Serviceable with their own custom lookup lifecycle).
And they can continue to do so.
I get the feeling that we're talking about different things. Let's look at
something more concrete.
What I'm talking about is this: Take the current lifecycle defined by
framework, and replace the 6 resource-delivery lifecycle interfaces with a
single interface. Leave all the other interfaces unchanged.
That is, remove LogEnabled, Contextualizable, Serviceable, Composable,
Configuration and Parameterizable. Replace those interfaces with something
like:
public interface Component
{
void setContext( Context context );
}
Where Context has methods that a component can use to get a logger,
configuration, parameters, services, data, and whatever else it needs. Maybe
it has a single lookup() method. Maybe it has a getter method for each type
of resource. Maybe both. Maybe it can be cast to various things, maybe it
can't. Doesn't matter.
Now do the same with the lifecycle stages. Replace enable-logging,
contextualise, service/compose, configure/parameterise with a single
lifecycle stage: set-context. This sits where the removed stages used to be:
immediately after component instantiation, and immediately before initialize.
Let's ignore the re* interfaces for now: Maybe they get collapsed in a
similar way, maybe they're replaced by listeners.
So, how does this modified framework compare with the current (v4) framework?
- When the component uses a single type of resource, they're the same: A
single method, lookup the resources.
- When the component uses multiple types of resources, the modified framework
is simpler: A single method, lookup the resources in the order most natural
for whatever the component uses them for. Current framework: multiple
methods, lookup the resources in the order defined by framework, hang on to
resources needed during later resource-delivery methods.
- In both cases, a component:
- Is not forced to implement lifecycle methods for stages it does not care
about.
- Can degrade gracefully when the container doesn't supply the resources the
component needs.
- In both cases, a container:
- Can add custom lifecycle stages.
- Can supply custom types of resources.
- Can choose not to supply resources of a particular type.
- In both cases:
- Each lifecycle interface can be used in isolation from the rest of
framework.
- New lifecycle interfaces can be added to framework without affecting
existing components.
- New types of resources can be added to framework without affecting
existing components.
- A container can adapt from modified to current framework, because the same
resource types are delivered to the component, and the modified and current
lifecycle stages sit at the same point in the component's lifecycle.
So what's missing? What can we add that demonstrates that the current
framework is really more flexible and scalable than the modified framework?
> > Whatever you happen to call this antipattern, taking a single real
> > concern and dividing it into several artifical concerns causes problems.
>
> I don't believe anyone has shown that they are "artifical concerns".
No. But that's what we're trying to figure out. And with lifecycle methods,
it's a case of "useless until proven useful". So far, noone has shown that 5
(or 6) resource delivery lifecycle methods are more useful than one.
--
Adam
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
