in reply to Re^2: Inheritance confused
in thread Inheritance confused

However, I have reason to keep the Base object inside {Parent}, as there are other constructors which will be invoked by other methods in Lite class.

There's a better way to do that by making the constructor in the parent class subclass-friendly. This involves checking the first argument you get in an OO constructor routine and identifying if it has a valid ref() associated with it. If you write your constructors as my example code below shows, you'll be making life easy for anyone else who wants to built on your code base.

In the code below, note a couple of things:

  1. Note that the $ex2 object in consumer.pl is created by using the constructor method of the $ex1 object, which is of the "Improved" subclass.
  2. See how the Parent class uses the ref() call to correctly determine when a subclass is re-using the Parent's constructor method.

Here's the example code structure:

File: consumer.pl

use strict;
use warnings;
use lib '.';
require Ex::Improved;

my $ex1 = Ex::Improved->new();
# Show that the parent's constructor still works:
my $ex2 = $ex1->new();

$ex1->setColor('green');
$ex1->setFood('bean');

$ex2->setColor('red');
$ex2->setFood('radish');

my $count = 0;    # count each object we display
for my $obj ($ex1, $ex2) {
    printf "Object: %d\n", ++$count;
    printf "Color: %s\n", $obj->getColor();
    printf "Food: %s\n", $obj->getFood();
}

[download]

File: Ex/Parent.pm (the parent class)

package Ex::Parent;
use strict;
use warnings;

sub new {
    my $class = shift;
    # This line lets subclass-created objects work:
    $class = ref($class) || $class;
    return bless { }, $class;
}

sub getColor {
    my $self = shift;
    return $self->{color} // undef;
}

sub setColor {
    my $self = shift;
    $self->{color} = shift or return 0;
    return 1;
}

1;

[download]

File: Ex/Improved.pm (the subclass)

package Ex::Improved;
use strict;
use warnings;
use parent 'Ex::Parent';

# This "improved" class lets callers get/set Food too!

sub getFood {
    my $self = shift;
    return $self->{food} // undef;
}

sub setFood {
    my $self = shift;
    $self->{food} = shift or return 0;
    return 1;
}

1;

[download]

Replies are listed 'Best First'.
Re^4: Inheritance confused
by exilepanda (Friar) on Dec 08, 2015 at 07:03 UTC
    Thanks Apero,

    The way you suggested can resolve the method calling issue. But this won't able to the make the {Parent} attributes shareable in different constructors in Lite in my case.

    That said, with my Lite class, I might have 

      $admin = MyTest::Lite -> asAdmin( $id );
  $user = MyTest::Lite -> asUser( $id );

    [download]
    where a data dump will give something like: 
      $admin => {
    Mode => 'Admin',
    CommonParentAttributes => {...}
  }, MyTest::Lite

    [download]
    and 
      $user => {
    Mode => 'User', 
    CommonParentAttributes => {...}
  }, MyTest::Lite

    [download]
    I don't actually mind if Mode is written into the CommonParentAttributes (thus I don't need CommomParentAttributes at all) , but when $user is created, $admin's Mode will become 'User'
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom