OO-style question

[Ovid]

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]

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;

What I don't want is

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

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.

[merlyn]

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

[tye]

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;

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")

[Adam]

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.

[coreolyn]

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 !-)

[merlyn]

How much more proof do you need besides http://www.deja.com, http://www.imdb.com, http://www.slashdot.org, http://www.etoys.com, http://cbs.sportsline.com, and any of the other top quarter of the Net that uses Perl from top to bottom?

Why is everyone still waiting for a verdict. It's in. Perl works, for little stuff, and for big stuff. Use it.

-- Randal L. Schwartz, Perl hacker

[coreolyn]

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 2^nd 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 !-)

[footpad]

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?