in reply to Loading a different Module depending on the Configuration

What you're describing is (if I recall correctly) a 'factory' pattern. Try something like this (untested code) 
package TheDb;

use strict;
use TheDb::PlainText;
use TheDb::SQL;

sub new {
   my $class = shift;
   my $type  = shift;

   my $full_name = "TheDB::" . $type;
   return $full_name->new;
}

1;

[download]
Basically you write one package that uses in all the others. The new method for that package just creates an object of the type you ask for and returns it. Each of your 'TheDB::' object inherits from, say, 'TheDB::Base'.

/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

Replies are listed 'Best First'.
Re2: Loading a different Module depending on the Configuration
by dragonchild (Archbishop) on Sep 26, 2001 at 21:44 UTC
    It's also called a 'polymorphic constructor'. I wouldn't reccomend this as good OO practice, but it's certainly ok.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
Re: Re: Loading a different Module depending on the Configuration
by skazat (Chaplain) on Sep 27, 2001 at 08:31 UTC

    hmm,

    the idea is to have the actual methods and whatever way you store and fetch stuff plugable, so, down the line I can say, 

     
my $scheme = 'FooSQL';
my $h = TheDb->new($scheme);

    [download]

    And, perhaps someone else, with a different setup and wants will go:

     
my $scheme = 'DB_File';
my $h = TheDb->new($scheme);

    [download]

    having all the subclasses loaded at the same time would be incredibly wasteful and useless, since I may not know exactly what DB (or subclass module) is there.

    This may seem like more work, why would you have n ways of doing the same thing? Well, you may not have a Spiffy SQL and are OK with using a plaintext solution, knowing some performance woes.

    This is for a very mature, stable app, not a quick 15 minute script.

    -justin simoni
    !skazat!

[reply]
[d/l]
[select]
      This is for a very mature, stable app, not a quick 15 minute script.

      <sarcasm>Heh, he he, ha HA! HAHAHAAHA!</sarcasm>

      Seriously, what school of Software Engineering did you graduate from - do you really think that using a Factory Pattern is something that a script kiddie would come up with? It's a very common Design Pattern.

      i do appreciate your desire to write your app 'The Right Way' - i really do, but sounds to me like you are too worried about 'false optimization' - imagine a interstate with a lovely 8 lane bridge that has been carefully constructed to maximize car flow ... only to be followed 2 miles down the road by a one lane bridge that you have no control over - that's false optimization.

      You have a lot of good clues here on this thread on how to solve your problem - take these ideas and run with 'em! Sounds to me like a factory pattern, or as dragonchild called it, a 'polymorphic constructor' - is a pretty valid idea for this problem. If you don't like that - then you might want to rack your brain against an Abstract Factory.

      But as for being concerned about loading subclasses that won't be used for a particular run of the app - do you _really_ need to concern yourself with that? And even if you do - doesn't that sound like a job for the _next_ version? (nudge, nudge) ;)

      jeffa

[reply]

        Seriously, what school of Software Engineering did you graduate from

        I'm 20 years old and going for a Bachelors in Fine Arts, I think I'm doing pretty well, I've never taken a CS class and I barely passed Algerbra 2 in High School. I have interesting ways of solving things.

        It seems to me that loading up each and every module that *could* be used is wasteful, also since I want to allow n number of different DB schemes.

        I'm going to solve this problem in a similar manner as AnyDBM_File does, since it pretty much has the exact mechanism that I'm looking for.

        I probably should have mentioned that each scheme to do the dirty work is a bit more complext than fetch() store(), there's also searches and thingies that actually print and return interesting things.

        do you _really_ need to concern yourself with that? And even if you do - doesn't that sound like a job for the _next_ version? (nudge, nudge)

        This could theoretically be the next version, although this particular app version has been going on heavy development since the .0 release last July (2000) . There is absolutely no way I'm starting from scratch, alone on a 1 meg program written in Perl

        I talked to my accountant (my wallet and my college bill) and thought that if I could release, say a totally Open Source and Free version of this particular program, making the Base Module LGPL'd, have a plain text version GPL'd and have, say a Postgres or MySQL version proprietary (ie, sell the SQL version) I could help myself out, and at the same time, make the transition relatively painless, if I decide to just go with a SQL backend. A pluggable achitecture will also allow other developers to create their own solutions and that'll keep the vitality alive for the program itself.

        I may draw pretty pictures all day, but you get a lot of thinking done in the process :)

         

        -justin simoni
        !skazat!

[reply]

In Section Seekers of Perl Wisdom