in reply to Objects in PERL

You're trying to replicate multiple inheritence in perl, which, while not impossible, is generally (*) a bad thing.

One possible adjustment for this is to keep your PERSON class, but instead of subclassing it, create an OCCUPATION (or a different term to represent 'relationship to your program' without using RELATIONSHIP) base class; PERSON would then have as an object member a one-to-many array of OCCUPATIONs. Your VENDOR, CUSTOMER, and EMPLOYEE classes then subclass from OCCUPATION.

*subject to one's personal interpretation of the matter; some people believe multiple inheritence is a work of pure evil, some believe it's manna. I'm of the opinion that if you believe the only solution is multiple inheritence, you've got something wrong in your object model.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
It's not what you know, but knowing how to find it if you don't know that's important

Replies are listed 'Best First'.
Re: Re: Objects in PERL
by Vuud (Novice) on Aug 25, 2001 at 07:57 UTC
    Okay, so then my PERSON class would just create and maintain an object for each role a person could play. At that point they are not that complicated, so I dont think creating an OCCUPATION class to subclass off of would be necesary.

    I thought the multiple would be good to do. I guess I will try it the other way

    Thanks for the help! "I'm never going to work another day in my life. The Gods told me to relax... I'm gonna be hooked up right"

[reply]
      First off, now that I've slept on it, I think ROLE is a better name for a class than OCCUPATION. But I'll stick with the latter for now.

      The only reason I'd define some OCCUPATION class is that while perl is not strongly typed, this allows you to check to make sure that a 'addOccupation' works right, and that you have some expected functions in which you can use in a call such as 'queryOccupations' in the PERSON class. The base class can be as simple as simply having a name of the occupation and a method to get it.

      -----------------------------------------------------
      Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
      It's not what you know, but knowing how to find it if you don't know that's important

[reply]
      At that point they are not that complicated, so I dont think creating an OCCUPATION class to subclass off of would be necesary.

      This is called using a Servant class, ie having one classes' attributes and members thrown into the master class, even though they should be in a seperate object. Generally it's best to avoid this, all you save is a little bit of performance at the expense of breaking your encapsulation.

[reply]

In Section Seekers of Perl Wisdom