Re: Re: Objects in PERL

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"

Comment on Re: Re: Objects in PERL

Replies are listed 'Best First'.
Re: Re: Re: Objects in PERL by Masem (Monsignor) on Aug 25, 2001 at 15:28 UTC
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]
Re: Re: Re: Objects in PERL by mugwumpjism (Hermit) on Aug 26, 2001 at 06:43 UTC
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]