Re: General Question about Config Files and IoC

First of all, thanks for all the great feedback.  I do have another 
question, though:

What are the reasons for using an interface rather than an plain class 
as the configuration parameter?

I am assuming that the ObjectAConfig class is a simple holder of data 
which will be retrieved and used withinn ObjectA.  Rather than 
implementing the interface, any other client that wants to reuse it 
would simply populate an ObjectAConfig object with the appropriate data.

I'm sure there are good reasons to use an interface, but I'd like to 
hear some concrete examples, because this is an issue that I think about 
a lot.  It seems to me that there is a lot of overhead to extract out 
and maintain a well-documented interface that duplicates the real class, 
"just in case someone ever wants an alternate implementation".  I have 
trouble thinking of real examples that justify this extra work.

Thanks,
Chad

Paul Hammant wrote:
> Peter, Chad,
>>>>> Do I need to make a separate "ObjectAConfig" class, which just holds 
>>>>> the config settings from the file, and then have a constructor like 
>>>>> this:
>>>>>   new ObjectA(objectAConfig, objectB)
>>>>>
>>>>> Is this the preferred approach, or am I missing something?
>>>
>>> I believe that is the preferred approach when doing constructor-based 
>>> dependency injection.
>>>
>>> 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.
> 
> - Paul