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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.