Maybe I shouldn't have mentioned the subclasses, because they are irrelevant to the issue. "Trying to give it configuration values without ever giving them" is a decent description. I don't want my application code to have to pass them in. I could do this by having a MyApp::Config class that it uses to get these values, but ideally I would like this class to not be tied to that specific config class (at least not to that class name) since it will be different for each project. Usually this means a factory of some kind, so that you can specify that on this project, the config class is called MyApp::Config, and my class can just ask the factory for a config class. (Hence my earlier comment about a config file telling where my config file is...)

Another solution is to have a registry of some kind (e.g. JNDI in Java), which is basically what your environment variable suggestion would amount to. That's not terrible either, but gets unwieldy at a certain point. By the time I have more than two ENV variables, I usually want them in a conf file of some kind.

What I've decided at this point is that it's too small an issue to worry about yet, and I'll just hard-code the name of the config class for now and wait until I have things more complex than DBI parameters to worry about. If you're interested in how people handle this in other languages, see Martin Fowler's article on the subject.