>>>>> "Adam" == Adam Murdoch <[EMAIL PROTECTED]> writes:
>> Currently it is very easy to extend AbstractLogEnabled to have
>> logging established. Can we achieve the same level of convenience
>> with the new approach?
Adam> Yep, using something like this:
Adam> public abstract class AbstractConfigurable implements
Adam> Configurable { public final configure( ConfigurationManager
Adam> configMgr ) { m_configMgr = configMgr; configure(); }
Adam> protected Logger getLogger() { ... } protected
Adam> Configuration getConfiguration() { ... } protected Context
Adam> getContext() { ... } ... etc ...
Adam> protected void configure() // Could make this abstract { }
Adam> }
Adam> Where subclasses implement configure(), rather than
Adam> configure(ConfigurationManager), if they need to do any
Adam> configuring.
So I have to keep in mind 2 different contracts in place of 1?
Looking at this from container perspective doesn't make things
prettier. In place of:
ContainerUtil.enableLogging(component, logger);
ContainerUtil.contextualize(component, context);
ContainerUtil.configure(component, configuration);
ContainerUtil.parameterize(component, parameters);
we will be doing something like:
ConfigurationManager configManager =
new BundleConfigurationManager(logger, context, configuration, parameters);
ContainerUtil.megaConfigure(configManager, component);
The new way seems to be more work for the container since it has no way
to find out if the component needs any of the objects above. It also
requires an extra ConfigurationManager instance per component (which was
not needed at all before). And in the end all we do is bundle things up
on one end of the call only to have them disbanded on the
other. Granted, we do less instanceof operations.
Adam> With this kind of approach, we not only have an equivalent of
Adam> AbstractLogEnabled, but we also handle AbstractConfigurable,
Adam> AbstractContextualizable, AbstractParameterizable, etc, all in
Adam> one.
If I wanted all in one, I would just build an AbstractEverything which
implements all our current interfaces.
Look at it from a different perspective: I just lost granularity.
Previously I could build things gradually by implementing standard
interfaces. Now I have to invent new interfaces to achieve the same
level of granularity.
I guess it boils down to:
* my feeling that granularity is good
* my distaste for complex class hierarchies
Thanks
Greg
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
