|There's more than one way to do things|
Program configuration in the OOP worldby Tardis (Pilgrim)
|on Apr 10, 2002 at 12:33 UTC||Need Help??|
Tardis has asked for the
wisdom of the Perl Monks concerning the following question:
My quest of creating a clean, strucutured, OOP-good set of programs and modules continues.
So far I have nicely abstracted my handling of various object types into seperate modules (each of which inherit most of their stuff from a superclass - less work for me so it's all good). I have also abstracted out the database layer into a seperate Backend module. Also good.
Now before I start to think about writing some bona-fide applications, I need to think about configuration data. The last thing I ever want to do in my new world of OOP-goodness is hardcode in directory paths and database access credentials. I'd rather eat a copy of Windows XP Home.
So now I'm puzzling about how to get data from a config file into my programs. Some criteria:
My best idea so far is to have a Config package which reads the config file during a class constructer. Then the first time my Config package gets used, the data is read in, otherwise it's unnecessary.
Then, provide Class Methods to get at the config data. Probably simplest is an AUTOLOAD method which looks up the config values from a hash.
Problems I see with this:
The key here being that if the Config module already 'knows' that is has an existing config object from a previous call, it will just pass that one back to the caller, so all modules/programs get the same data, and the config file need to be read only once.
In effect, each Config->new() call will merely get back the same reference to the single object, it is held in the Class and only created during the first Config->new call.
The other nice thing about this is that the new method could be modified so a config file override parameter could be passed in. So my user program can use that, and my called modules don't know the difference.
Flaws? Criticism? Pizza?