sschneid has asked for the wisdom of the Perl Monks concerning the following question:

This is an OO-based question that I've struggled with ever since I decided to dive into the OO-world, and still haven't really figured out. Maybe one of you can help my understanding.

The basic set-up is as follows:

Say I have three classes, Blah, Blah::DB, and Blah::Project:

Blah: this is the main program.
Blah::DB: contains all sorts of common functions I use to retrieve 'stuff' from a database.
Blah::Project: contains functions that I use to deal with 'projects'.

In Blah.pm, I'm doing the following: 
my $db = Blah::DB->new(
  database => 'blahDB',
  user     => 'scott',
  password => 'p455w0rd'
);

[download]
Which is peachy, because now I can do things like $db->tablelist(); and whatnot.

The problem is: can I inherit the functions I use in Blah::DB into my Blah::Project package? Maybe all of my 'projects' are stored in a database, and I want to retrieve them and them store them in a 'project' object. I can't figure out a way to use any of the Blah::DB functions, however, without either:

a) creating a new Blah::DB object from within Blah::Project, or
b) pass my Blah::DB object to Blah::Project when I create a Blah::Project object (my $proj = Blah::Project->new($db);).

Neither of these seem elegant.

Can someone point me in the right direction?

-s.

Replies are listed 'Best First'.
Re: OO, inheriting functions from other packages
by perrin (Chancellor) on Jul 22, 2004 at 16:16 UTC
    Getting access to functions is not what inheritance is for. Inheritance is used when you have a class that is just like another class except for some variations in behavior of specific methods. Most of the time, the relationship between classes is "foo has a bar" not "foo is a bar." When in doubt, don't use inheritance.
[reply]
      Maybe 'inherit' was the wrong word to use. Semantics, schemantics! ;)

      -s.
[reply]
        Semantics, schemantics!

        Semantics, indeed! It makes a very big difference whether you meant inheritance, or something else. Each approach has different pros and cons, so using one term when you mean another has major ramifications for any answers. I'm not trying to hammer you for making a mistake in terminology -- we all do that now and again -- but it is an important thing to keep in mind.

[reply]
Re: OO, inheriting functions from other packages
by guha (Priest) on Jul 22, 2004 at 16:22 UTC

    Maybe Class::Singleton, which would be your b-option but more elegant in your wording.

    At startup you would create your $dbh, and all subsequent use of the constructor would give a reference to the first $dbh.

[reply]
      I think that, at first glance, this is what I was thinking. Something about having multiple objects that all do the same thing spread throughout packages seemed wrong. I'll look into it, thanks!

      -s.
[reply]
Re: OO, inheriting functions from other packages
by dragonchild (Archbishop) on Jul 22, 2004 at 18:25 UTC
    You will want to pass the $db into your Blah::Project instances. A Blah::Project has-a Blah::DB. So, you need to hand the Blah::Project the instance of Blah::DB that it's supposed to use.

    A few quibbles:

    • It's customary to call the database handle $dbh, not $db.
    • It's customary to do something like my $proj = Blah::Project->new( dbh => $dbh );.

    You weren't wrong ... it just looked weird. :-)

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

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]
[d/l]
Re: OO, inheriting functions from other packages
by davorg (Chancellor) on Jul 22, 2004 at 16:05 UTC

    I wonder if you can just save yourself a lot of time by using Class::DBI.

    --
    <http://www.dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

[reply]
      I think you misunderstand. I'm not writing my own DBI package, I'm using a package for common database searches (and whatnot) used through the app.

      I'm also not talking specifically about using the Blah::DB (database functions, I mean) package throughout other modules; it's others, as well. If I have Blah::Calendar, and I want several of the other packages use calendar functions, etc etc.

      -s.
[reply]
        This sounds like the question of should i inherit from a base class, or should i include an instance of some other class in my class. What i mean is, if you have a calendar class, and you want calendar functionality in a basically unrelated class, such as some specialized DB class, you probably dont want to have the DB class inherit from the Calendar class, you probably want an instance of the Calendar class in the DB, which then has a well defined interface. 
        package MyDBClass;

use MyCalendar;

sub new {
   my $class = shift;

   ...
   my $self = ...;
   ...
   $self->{'_calendar'} = MyCalendar->new();
   ...
   return bless $self, $class;
}

sub Calendar {
   return $self->{'_calendar'};
}

...

        [download]
        Then you have a calendar as a data element of your DB class, and you can do things like: 
           my $db = MyDBClass->new();

   $db->Calendar()->CalendarFunction(...);

        [download]
        Now there are other, more sophisticated ways to deal with the calendar in the DB, but this should illustrate the point.

        The moral is, if a class wants some other packages functionality, it doesnt have to be a child class, it can just use the other class.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom