Re: OO Design question: configuration (Encapsulate the knowledge about an object within the object itself)

[mr_mischief]

I'm far from an authority on OO, but my first instinct would be to encapsulate the knowledge about what each object needs as far as configuration within the object itself.

Having one object that grabs all the configuration and holds it is a great idea, especially when the storage on disk or eslewhere might change. Having the configuration object know a lot about the insides of the other objects I think violates the encapsulation for which you chose OO in the first place. It's probably best for the configuration object to get and hold the configuration, then make a flexible interface for each other object ask it for what they each need.

I'd pass a reference to the config object into all the other objects. I know that's a pain, but it's what I'd do out of the alternatives. I'd make sure the configuration object had a nice way to get the values out, either as a hash or as individual key/value pairs. Something like:

my %conf_val = %{ $conf->values( 'conf_section' ) };

or

my $val1 = $conf->value( 'conf_section', 'conf_item' );

The configuration object then doesn't need to know which objects need which configuration items, let alone how they need them. It just needs to be able to provide what is asked of it, and to do it in a predictable way. The other objects don't need to know how the config object gets or stores the values, or even whether it's eagerly or lazily. This is, as I understand it, one of the biggest advantages to using OO.

Of course, it's not likely you'd need two or more configurations in a single running program. In this particular situation, a globally accessible object that returns the values it is asked to return may be a good compromise. It'd surely be ahead of making the configuration object aware of each of the other objects on my list. In fact, making the configuration object's behavior depend on the calling object wouldn't even be on my list.