What kind of configuration information are you passing around? I'm sensing from your question that there might be a bit of over-engineering going on here. Usually, everything needed to "configure" an object should be available when it is constructed.

-sauoq
"My two cents aren't worth a dime.";

the program I am writting implements a Proxy Ldap Server. One object receives the requests, gets from an object ConnectionList one object Connection for every connection the server handles. The object connection needs information which server it has to contact, on which machine and which port.
The module which holds together the whole cabuddle reads the configuration information and makes it available to the Connection Object.
It should be possible also to get the information from other sources, for example RDBMS, so the connection information the object "Connection" needs may be different.
yes, the information is handed over to the Connection object when it is constructed.

cheers
reinhard

The module which holds together the whole cabuddle reads the configuration information and makes it available to the Connection Object.

And you are primarily concerned with how it hands that information over? I'm guessing you don't need anything much more complicated than a hash that you pass by reference. If you need to perform some operations on the data that have nothing to do with either the "module which holds together the whole cabuddle" or with the connection object which is storing this data, then you could wrap it all up in another object. (ConnectionConfig?) I doubt that's necessary though.

-sauoq
"My two cents aren't worth a dime.";

You could have an object you pass around, or you could use a Singleton design pattern - to allow all classess/methods you care about to find the configuration information.

If you wrap use one of the many existing configuration file readers inside your singleton you'd also not be hard-wiring entries.