Re: General Question about Config Files and IoC

peter-4lf8KW9E9MLMqX/[email protected] wrote:

>>>Of course, it doesn't have to be an 'ObjectAConfig' class, it could be
>>>a Properties object, a DOM document, or anything else.. but there is
>>>the general principal of passing a representation of the config via
>>>the constructor.
>>>      
>>>
>>I'd always suggest not doing a Properties or DOM object via the ctor. It
>>is too vague.  An interface to represent the the configuration, with
>>multiple possible implementations is my preference.
>>    
>>
>
>I would always opt for a concrete Configuration object with multiple
>strategies for building that configuration object if needed. ie
>
>ObjectA
>ObjectAConfig
>XMLObjectAConfigBuilder
>DBObjectAConfigBuilder
>...
>
>That is much easier to evolve over time IMHO.
>
>  
>
I am inclined to use interfaces rather than this approach.  In strict 
constructor-based dependency injection, using these Builders seems to be 
more complex for no gain.

There are some other advantages to proyal's suggestions that, although 
less compelling, still deserve mention.
- If you create a component that uses several other components, your 
configuration class can implement the configuration interfaces of each 
of your dependencies.
- An intriguing one that's been in the back of my mind: a container 
programmer who likes magic (not Leo) :) could transparently manufacture 
configuration classes using XML config files, JMX, or who knows what.  
Iirc, standing in for concrete classes is harder than interfaces with 
the libraries people are currently using; maybe someone more experienced 
than I can jump in.
- An interface feels more elegant to me... I tried to write this one 
more convincingly, but I think it's just an aesthetic thing. :)

--ryan