Re: [RT:A5] What are the _real_ concern areas?
Adam Murdoch <[email protected]>
| Newsgroups | gmane.comp.jakarta.avalon.apps.devel,gmane.comp.jakarta.avalon.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 19 Dec 2002 06:16 am, Greg Steuck wrote: > >>>>> "Berin" == Berin Loritsch <[email protected]> writes: > > Berin> What about merging Contextualizable, Configurable, and > Berin> Parameterizable? > > Berin> i.e. > > Berin> interface ConfigurationManager > Berin> { > Berin> Logger getLogger(); // can be its own interface... > Berin> Context getContext(); > Berin> Configuration getConfiguration(); > Berin> Properties getProperties(); // replace the proprietary > parameters. Berin> } > > Currently it is very easy to extend AbstractLogEnabled to have logging > established. Can we achieve the same level of convenience with the new > approach? Yep, using something like this: public abstract class AbstractConfigurable implements Configurable { public final configure( ConfigurationManager configMgr ) { m_configMgr = configMgr; configure(); } protected Logger getLogger() { ... } protected Configuration getConfiguration() { ... } protected Context getContext() { ... } ... etc ... protected void configure() // Could make this abstract { } } Where subclasses implement configure(), rather than configure(ConfigurationManager), if they need to do any configuring. With this kind of approach, we not only have an equivalent of AbstractLogEnabled, but we also handle AbstractConfigurable, AbstractContextualizable, AbstractParameterizable, etc, all in one. Which just can't be done when info delivery happens across multiple lifecycle interfaces. -- Adam