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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
