I'd use subclassing, and class methods. That way you can override base methods, and leave in others...

Do be aware that when calling a method, an extra first parameter is introduced: the class name, when calling it as a class method (or an object when calling the same sub as an object method).

As for the command line, I'd just use the -MFoo=bar syntax, to load the master module (Foo, file "Foo.pm"), and use the parameter ("bar") to actually load the submodule (Foo::bar, file "Foo/bar.pm"). Just like B/O do. For example, the command line switch -MO=Xref loads the module O, calls its import with parameter "Xref", which in turn loads B::Xref. So, you know where to look for an example implementation... :)

Actually you can also take a look at File::Spec and AnyDBM_File too, to see how those modules dynamically change their behaviour by loading a backend module, and then "patch themselves". That way your code can be oblivious of what backend is actually being used.

If that's too advanced to implement for your taste, you could instead simply use a global variable to store the package to use in the method calls, like

$pkg = "Foo::bar";
my $rate = $pkg->rate('basic');
[download]

or have an (empty) global object, blessed into that class:

$calculator = Foo::bar->new;
my $rate = $calculator->rate('basic');
[download]

which would require very little change in your actual implementation.

Finally, you could have the base module export its functions, and have those refer back to the backend methods. Your code could simply call rate('basic'), which would invoke the function Foo::rate, which in turn would call Foo::bar->rate('basic'), which in turn could be inherited from Foo::Base, a class which you can actually implement inside Foo.pm.

Let me know if any of these ideas appeal to you, so I can bother with actually fleshing it out a little.