in reply to Best practice with polymorphic constructors
First of all if you have reason to force code to be kept in sync (and keeping names/passwords in a config file is good enough reason for me) then you can partially alleviate the problem by putting in run-time sanity checks. For instance use Carp.pm and confess away if someone tries to connect that you don't know about, or if your config file doesn't have all of the information that you expect. While having no synchronization is best, a close second is to have rapid and detailed feedback upon breakage.
The second is about your indentation style. Yes, I know that a lot of people line up their indentation like that, but it is a maintanance hassle and comprehension is inhibited when indents go to 6 or more spaces in. My style is that if I am forced to move to another line, then I hit return and indent as I would for a block. YMMV on that, but consider how fast you indented way past 80 columns.
I don't like having the config file hardcoded into the module. What I use at work is a (sorry, proprietary) configuration module that avoids having any hardcoded file names. Rather have an access method of some sort which decides where to get the configuration from dynamically. Why? Well that makes tracking down all of the configuration files that you are using a lot easier. It makes it easier to separate development from production. (Each just picks up configurations with slight but significant distinguishing features - like what database to connect to.) And if you code the configuration logic correctly, you can have it pick up tyops in your configuration file.