Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^2: OO, inheriting functions from other packages

by sschneid (Deacon)
on Jul 22, 2004 at 16:07 UTC ( [id://376635]=note: print w/replies, xml ) Need Help??


in reply to Re: OO, inheriting functions from other packages
in thread OO, inheriting functions from other packages

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.
  • Comment on Re^2: OO, inheriting functions from other packages

Replies are listed 'Best First'.
Re^3: OO, inheriting functions from other packages
by shemp (Deacon) on Jul 22, 2004 at 16:17 UTC
    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'}; } ...
    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(...);
    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.

      Or more succintly, "favor object composition over class inheritance."

      And yes, i agree that this is good place to honor that rule, but i would code it the other way around, that is, instead of a DBI having a Calendar, the Calendar should have the DBI:

      package MyCalendar; use MyDBI; sub new { ... $self->{'_dbh'} = MyDBI->connect( ... ); ... }
      And connect() should only create a new database connection if an existing database connection does not already exist (that is, MyDBI is a Singleton or behaves like one). Or, as dragonchild suggests, you could simply pass the database connection to the object in question when you instantiate it. But either way, the Object hasa database connection, and the client can (theoretically) not have to learn SQL. ;)

      Disclaimer: In reality, i think plain ole DBI's selectall_arrayref() with the {Slice => {}} attribute function parameter offers plenty of power, flexibility, and maintainability, and it takes less time to develop with. But as always, Your Mileage May Vary and There Is Always More Than One Way To Do It.

      jeffa

      L-LL-L--L-LL-L--L-LL-L--
      -R--R-RR-R--R-RR-R--R-RR
      B--B--B--B--B--B--B--B--
      H---H---H---H---H---H---
      (the triplet paradiddle with high-hat)
      

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://376635]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2024-04-25 09:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found