in reply to Re: sub classing best practice
in thread sub classing best practice

In answer to some of the questions...

Both need to use the same authentication mechanism, supplied through 4 arguments. And because of state issues, the authentication state needs to be shared across all transactions. Parent object is authentication + global attribute maniputation, sub classes are manipulation of specific items - in this instance contacts, identities and messages.

My current solution is indeed:

my $subobj = $obj->subclass;

But to me, that doesn't intuitively say I'm creating a new subclass object.

How many years is it 'til Perl 6 again? ;-)

Replies are listed 'Best First'.
Re^3: sub classing best practice
by jbert (Priest) on Dec 11, 2006 at 16:12 UTC
    Isn't this more of a has-a, rather than is-a? The name of the superclass might give a clue here.

    For example: If it is "Credentials", then I would say that a Message has Credentials, rather than a Message is-a Credential.

    If the different actions are related to each other and can benefit from having a common base class, it might make sense to have an abstract base class which has their shared code/interface etc. But that needn't be the same as your Credentials class.

Re^3: sub classing best practice
by Joost (Canon) on Dec 11, 2006 at 16:10 UTC
Re^3: sub classing best practice
by polettix (Vicar) on Dec 11, 2006 at 16:20 UTC
    But to me, that doesn't intuitively say I'm creating a new subclass object.
    That's why I was suggesting to rename the method to something more readable, like subclass_clone(). Anyway, I agree with Joost about the fact that the authentication stuff should probably reside in an object by its own, whose services are used by your specific manipulation classes.

    Flavio
    perl -ple'$_=reverse' <<<ti.xittelop@oivalf

    Don't fool yourself.