user configuration options in software

I am interested in your opinions on how to handle user options in software.
I see three options at the moment, but I am probably missing something.

I have a function foo() that opens a file, and then does something else. There is a seperate config class, which has a property filename, which contains the file I want to open. I know I could also use global variables  or something like that, but I like the explicitness of using a module or a class.

Option1 (in python, should be self-explanatory):
def foo():
    """call as foo(). depends on config class being known/initialized"""
    open(config.filename)
    bar(config.someoption,config.otheroption)

Option2:
def foo(config):
    """call as foo(config)"""
    open(config.filename)
    bar(config.someoption,config.otheroption)

Option3:
def foo(filename,someoption,otheroption):
    """call as foo(config.filename,config.someoption,config.otheroption)""""
    open(filename)
    bar(someoption,otheroption)

I hope I explained my problem clearly. Are there any books that cover these kind of issues? Is it too simple?

Too many options
Monday, April 19, 2004

Is there some reason you don't want to make foo one of config's methods? 

Anony Coward
Monday, April 19, 2004

Among those three options, I would definately choose option number 2. I also agree with the second poster.

Karin
Tuesday, April 20, 2004

I vote for option 3.  I feel code should be configuration agnostic.  I came to this conclusion when I wanted to grab some classes from a different project here at work to incorporate into my own project.  They did exactly what I want, except they were tied to the configuration from that project.  I had to hunt through the code to find all the configuration tie-ins before I could make it work for me.

Of course, depending on the scope and size of the project, the KISS principal can make a good argument for the other two options.

madking
Tuesday, April 20, 2004

how about option 4:

def foo(filename,someoption = config.someoption,otheroption =config.otheroption ):
    """call as foo()""""
    open(filename)
    bar(someoption,otheroption)

i guess this could work if your options are strings or ints.

just-thingking-aloud.
Tuesday, April 20, 2004

That'll only work if the function is defined after the config object is created, and the config.someoption and config.otheroption attributes have been set. Also won't work if you later change the values of config.someoption, etc.

David M. Cooke
Tuesday, April 20, 2004

I also like to have the code be totally independent of the configuration, so I lean towards option 3. But of course, this code is simplified, so I will get functions with many parameters.

As for making foo() a method of config: foo() actually is a method of another class, the code has many classes, and I would like to have the configuration information (read from registry/.ini file etc.) in one place.

It seems like there is not really one obvious way to do this.

Thanks for your input.

Too many options
Wednesday, April 21, 2004

When you have lots of parameters, you can always bundle them up into a containing class, to simplify method signatures.

Another option is to kind of combine options.  If you have a package which requires configuration options, create a package configuration object.  Classes inside this package can query this configuration object for their information rather than having lots of parameters to methods.  The application which uses this package can use whatever configuration mechanism it wants, and then it pushes the configuration information into the package configuration object.  This gives the seperation of concerns that I think you are looking for.

This does create an additional layer of indirection, so I would only use it where the design is large enough to warrant the additional complexity.

madking
Thursday, April 22, 2004

  Recent Topics

  Fog Creek Home