Ok, so let me see if I understand the issue:
- You have a base class that is responsible for creating a database connection.
- It creates that based on configuration arguments, thus making this base class extensible -- you can use it for a variety of database instances.
- You have a sub class that uses the base class.
- This class needs to use the base class's database connection, but you don't want this sub class to send config data to the base class.
Is that an adequate description? You want to use the sub classes, which implicitly use the base class? Would it be too much to add
use BaseClass;
BaseClass->connect(args...);
to the code that uses the sub-classes (that is, the main application)? It sounds like you're trying to give it configuration values without ever giving them. In that case, perhaps you should just use environment variables and be done with it.
package BaseClass;
sub connect {
...
$dbh = DBI->connect($ENV{PERRIN_DBI}, $ENV{PERRIN_USR}, $ENV{PERRIN_
+PWD});
...
}
Then you'd set those environment variables in your program (via BEGIN) or beforehand in your shell. It's basically the same as using globals, so if you're allergic to that, then this isn't for you either. ;)
_____________________________________________________
Jeff [japhy]Pinyan:
Perl,
regex,
and perl
hacker, who'd like a job (NYC-area)
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;
| [reply]
[d/l]
[select] |
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.
| [reply] |