Re: [configuration]More docs

[Oliver Heger]

Okay, I can live with this if condition for the two cases. If later 
other cases are added, this should be easy to refactor.

My code fragment contained the paranoia check whether the passed in 
Configuration object implements the XMLReaderProvider interface. If this 
is the case, the createXMLReader() method can be called (which at the 
moment would return either a BaseConfigurationXMLReader or a 
HierarchicalConfigurationXMLReader). Otherwise always a 
BaseConfigurationXMLReader is returned, which can handle all types of 
Configuration objects.

Oli

Eric Pugh wrote:

Wow...

I can't wait to read through your patch tomarrow..  Only have a minute, so I
thought I would address the XMLReaderProvider....
Maybe it is just me, but something I don't like about java and interfaces is
that sometimes I get so lost in all the interfaces..  Everything implements
an interface and behave's differently depending on which interface is being
used etc..
I think you are 100% right, if we had 3 cases..  But with two cases, I feel
like since we still have an if statement, we aren't gaining much.  If and
When we get the if/elseif/else structure, then I think that would be great..
Part of me wonders why it doesn't look like this:

      return new ((XMLReaderProvider) config).createXMLReader();,

why the BaseConfigurationXMLReader is differnet.  Why not have
BaseConfigurationXMLReader implement createXMLReader as well?
Eric

 

-----Original Message-----
From: Oliver Heger [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 8:12 PM
To: Jakarta Commons Developers List
Subject: Re: [configuration]More docs
Hi,

I followed Yoav's suggestion and created an example page with usage
examples for some of the features of ConfigurationFactory. I think if
another structure is preferred, the texts can easy be copied
and pasted.
The patch is in bugzilla with the bug id 24716.
Eric, I see your point with keeping the Configuration interface as
simple as it can be. A ConfigurationXMLDocument class is
surely a good
idea; it could also provide some other functionality like creating a
Document (dom4j or w3c), storing a Configuration object as
XML file, or
utility methods for Digester interaction.
There is only one thing I feel uneasy with: The new class
would have to
instantiate a specific ConfigurationXMLReader instance
depending on the
class of the actual Configuration object (there is one specific class
for HierarchicalConfiguration and one that handles the other
classes).
Code like
 if(config instanceof HierarchicalConfiguration)
 {
     return new HierarchicalConfigurationXMLReader(config);
 }
 else
 {
     return new BaseConfigurationXMLReader(config);
  }
would make every refactoring guru mad because such a problems
scream for
polymorphism. Would it be a solution to introduce a new interface,
something like XMLReaderProvider, with only a
createXMLReader() method?
Then we could have code like the following
 if(config instanceof XMLReaderProvider)
 {
     return new ((XMLReaderProvider) config).createXMLReader();
 }
 else
 {
     return new BaseConfigurationXMLReader(config);
  }
This is maybe a bit better. The base configuration classes would
implement this interface in a proper way. What do you think?
Oli
   



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]