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

I have a problem that I'm not sure of the best approach to take. I have a base class that has two sub-classes that inherit from it: 
          [base]
          /    \
         /      \
[subclass A]  [subclass B]

[download]
B has similar functionality to A. A returns some data, B writes the data to a file, but in a different format than the data returned from A. Under some circumstances, the data written to the file from B is in the exact same format as the data returned from A.

However, I don't want B to inherit A's methods as I don't want the user accessing them from the object. In other words, I might have 

my $object = A->new;
$object->someWeirdMethod;

[download]
What I don't want is 
my $object = B->new;
$object->someWeirdMethod;

[download]
But that happens if I inherit from A, unless I write a bunch of methods to trap those calls and let the user know they shouldn't do that.

The alternative seems to be having B instantiate an A object, but having subclasses instatiating instances of each other strikes me as problematic. I keep up that habit and I might start winding up with circular references that I'll have to explicitly destroy.

Summary: two options that I see:

  1. Have B inherit from A, but don't let people call A's methods from B.

  2. Have B instantiate an instance of A. I like this better, but somehow it feels wrong.
Any pointers? I don't do a lot of OO programming and I'd appreciate feedback as to the best approach to take.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
Re: OO-style question
by merlyn (Sage) on Dec 30, 2000 at 00:46 UTC
    If B doesn't seem natural responding to A's methods, then B is not an A, and you can't use inheritance. So more likely, B "has an" A, and some of B's methods will be implemented by delegating those to the A instance within B.

    But that brings back an odder question. Are B and A really both subclasses of the unnamed base class? Perhaps that's where your problem is.

    -- Randal L. Schwartz, Perl hacker

[reply]
Re: OO-style question
by Adam (Vicar) on Dec 30, 2000 at 01:35 UTC
    If you have a method that seems correct for both A and B, could it be in the base class? Maybe you need a third level, ie a base class, from which C,D, and E inherit, and then A and B could inherit from C. C could even be an abstract class.

    I disagree with Tye about Perl's inheritence. The big win in OO is inheritence, that and methods, so if you are going OO - go OO! The problem in Perl is that it is a bit kludgy when it comes to OO. Honestly, the more I work with Perl OO the more I think that a large OO project should be done in C++. It can be done in Perl (what can't be done in Perl?) but I'm not sure that it should be done in Perl. That is, large projects. Perl OO is great for smaller projects, even ones that use inheritence.

[reply]

      I think Perl still needs to be explored in large projects, and a comment about Perl being kludgy. It's Perl's kludginess I like. In comparison, Java seems so steril. The problem with Perl code on large projects is the level of efficiency demanded by the base functions(ok all of them).

      Perl's freedoms come at a price when coding in OO. The demands on the quality of every function begin to make exponential performance variations. In fact in the end (come on Perl 6!!) many of the exponetial problems that occur now may lessen with improved garbage collection, or is it that my code is just that sloppy ... hmmm

      Anyway I really think in the end Perl OO has a shot at Enterprise Acceptence even by the more conservative houses. C++ will always be highly demanded in such organizations, but Perl OO could open up even at the developer level in such corporations if it's objects could be of proven value in the enterprise's reusable component library.

      coreolyn Duct tape devotee.
      -- That's OO perl, NOT uh-oh perl !-)

[reply]
[reply]
Re: OO-style question
by footpad (Abbot) on Dec 30, 2000 at 09:27 UTC
    Ovid,

    With respect, it sounds like you need an additional class.

    A will handle the raw data access. B will return the data in one format and C returns it in another.

    Document the class you're most comfortable with the user having, privatize the rest.

    Also, keep the MVC (model, view, controller) model in mind. One data model, alternate views, controllers vary according to need.

    --f</p?

[reply]
(tye)Re: OO-style question
by tye (Sage) on Dec 30, 2000 at 00:58 UTC

    To answer this question well, we need more concrete information so we can make a call as to whether A is a B, B is an A, A is a Base, B is a Base, etc.

    But another option is that B can dispatch to A in any number of ways. The two simplest are: 

    sub B::same { goto &A::same }
# or
*B::save= \&A::save;

    [download]
    I'll add that inheritance, especially in Perl, should be saved as a last resort. Perl's inheritance is just way too clumsy, being very all-or-nothing.

            - tye (but my friends call me "Tye")
[reply]
[d/l]
Re: OO-style question
by coreolyn (Parson) on Dec 30, 2000 at 02:39 UTC

    I could be all wrong here, but your question (to me) reads like the definitions of polymorphism. That is to say you want an A structure but you wand to mash it into a B object. Isn't that how you exploit Inheritance Polymorphism?

    In otherwords It seems to me that even though it

    . . .somehow feels wrong

    your 2nd options is the correct one. But my opinion is not from practice on such a problem as yet.

    coreolyn Duct tape devotee.
    -- That's OO perl, NOT uh-oh perl !-)

[reply]

Back to Seekers of Perl Wisdom