in reply to object oriented Perl advice / constructor creation in child class

Well, your example doesn't actually show inheritance. Your constructor creates a "has-a" relationship, because your C1 objects will have one object of each of the classes A, B, C and D as attributes. This is a solid pattern in many cases, but it doesn't give you direct access to the methods of the four classes.

I'd say that today's perlish way to do OOP is Moose or its lightweight cousin Moo, and I definitely recommend those if you have several classes to inherit from. Here's a short example:

# package A; use 5.014; use Moo; sub say_hello { my $self = shift; my ($name) = @_; say "Hello, $name!"; } 1;
# package C; use 5.014; use Moo; has 'name' => (is => 'rw'); sub say_goodbye { my $self = shift; say 'Goodbye, ', $self->name, '!'; } 1;
# package C1; use 5.014; use strict; use warnings; use Moo; extends 'C'; use A; has '_a' => (is => 'ro', default => sub { A->new() }, handles => [qw(say_hello)] ); 1;
Now you can do things like this:
use strict; use warnings; use C1; my $c = C1->new(name => 'John Doe'); $c->say_hello('World'); $c->say_goodbye;

So, your C1 objects have direct access to both the say_hello method from, and the say_goodbye method from

Note that Moo (and Moose) will take care for object constructors: You don't write new methods!

If you want to do object inheritance without an object framework, you do it like this:

package C1; use parent (qw(A B C D));
However, in that case you need to take care for calling parent constructors and conflict resolution yourself, which is why I don't expand on this.

Replies are listed 'Best First'.
Re^2: object oriented Perl advice / constructor creation in child class
by smarthacker67 (Beadle) on Jul 11, 2018 at 06:16 UTC
    Yes, I agree its time to use Moose.

    My wild guess says

    Tie::Hash might be something I can utilize here but since never used before so finding it difficult use. Can Tie::Hash be used ?

      Sorry, but I don't see how Tie::Hash would help you here.

      In another reply you write that all your classes A to D already exist and have their own new methods, so Moo(se) inheritance (which makes Moose classes inherit from other Moose classes) isn't easily done either. As others have explained, Perl's method resolution with mro might help to some extent, but I doubt that it is worth the trouble. In any case you need to understand which of the methods you want to have available through the interface of C::C1 objects, especially with regard to their new methods.

      On whatever I've seen so far, I'd go for the delegation approach. The the existing classes don't have to be Moo(se) classes, and you explicitly implement the methods you want to make available through your C::C1 objects, and you can decide who should construct your A to D objects.

      package C::C1; # That's the perlish name for the module use File::FindLib 'lib'; use A; use B; use C; use D; sub new { return bless({ _a => A->new->bar, # I don't understand bar here _b => B->new->bar1, # nor bar1 here _c => C->new(), _d => D->new(), }, shift); } # now for any method of A: sub a_method_1 { my $self = shift; $self->_a->a_method 1(@_); } # etc # And for any method of B: sub b_method_1 { my $self = shift; $self->_a->b_method 1(@_); } # etc # Repeat for C and D, ad libidum.

      Maybe you want your users to read/write A to D? Here's an example for D:

      sub new_d { my $self = shift; if (@_) { $self->{_d} = D->new(@_); } return $self->{_d}; }
      Someone using C::C1 would write like this:
      use C::C1; my $c1 = C::C1->new; $c1->a_method_1(); # will execute A::a_method_1 $c1->b_method_1(); # will execute B::b_method_1 $c1->new_d(@params) # will execute $self->{_d} = D->new(@params)

      Moo or Moose can help to make your C/ more readable, because they have keywords for method delegation, as I've shown in my previous example. But before going deeper, I'd like to understand how the interface of your C/ should look like.