I have been thinking about this subject for a while. How about the
following scenario:
ConfigurationNode and Configuration are still separated, but it is
possible to open a sub configuration anywhere in the hierarchy. I would
therefor add a subConfiguration() method to the Configuration interfa
From my POV there is a difference between a ConfigurationNode and a
Configuration: a node is just a simple piece of data while a
Configuration is comprised by the whole hierarchy of nodes. It lies in
the Configuration's responsibility to maintain its nodes and to provide
methods for querying or
imho Configuration and ConfigurationNode should be merged into a single
class, because a Configuration is basically a node in a hierarchical design.
Emmanuel Bourg
Oliver Heger wrote:
I have been experimenting with a more hierarchical design for
configuration classes and would like to bring in
I have been experimenting with a more hierarchical design for
configuration classes and would like to bring in my results for
discussion. You can download a zip under
http://www.oliver-heger.privat.t-online.de/hierarchicalconfig.zip
What I have done so far is to extract the internal Node clas
