in reply to When to Use Object Oriented approach in Perl? (RFC)

Damian Conway has some great rules for when to use OOP, reproduced at Damian Conway's ten rules for when to use OO. I think these are still every bit as good today as they were way back when.
  • Comment on Re: When to Use Object Oriented approach in Perl? (RFC)

Replies are listed 'Best First'.
Re^2: When to Use Object Oriented approach in Perl? (RFC)
by thanos1983 (Parson) on Jul 31, 2014 at 23:59 UTC

    Hello AppleFritter,

    Thank you for your time and effort, I will definitely take a look. I am also reading the perlootut (the official tutorial) which also includes some rules apart from guidance.

    Again thank you for your time and effort.

    Seeking for Perl wisdom...on the process...not there...yet!
Re^2: When to Use Object Oriented approach in Perl? (RFC)
by einhverfr (Friar) on Sep 05, 2014 at 07:24 UTC

    The only one of those I am not sure about is the natural hierarchy/inheritance one. The big problem is the LSP and often data that seems to follow a natural hierarchy (a square is a rectangle) in fact violates the LSP.

    Inheritance is powerful but it is also very difficult to get right. On the other hand, one thing I really like about Moose is the fact that the roles and delegation systems provides a useful alternative to inheritance where what you really want to offer is a consistent interface.

      The only one of those I am not sure about is the natural hierarchy/inheritance one. The big problem is the LSP and often data that seems to follow a natural hierarchy (a square is a rectangle) in fact violates the LSP.

      Hmm, could you elaborate on this? As I understand it, the LSP stipulates that a property that holds for objects of a given type must not fail for objects of a subtype thereof.

      So suppose that you've got a class Rectangle, and a subclass Square. What property would be provable about instances of Rectangle that isn't provable about instances of Square? You can prove additional facts about the latter, of course, but I'm not seeing any property that's lost by transitioning from (general) rectangles to squares.

        How about the property that the width and height (of a Rectangle) are independent:
        package Rectangle; use Moo; has height => (is => 'rw'); has width => (is => 'rw'); sub demo { my ($self) = @_; printf "Demo of %s\n", ref $self; $self->show_dimensions; printf "Resetting height => 4, width => 3\n"; $self->height(4); $self->width(3); $self->show_dimensions; printf "area: %d\n", $self->area; $self->show_dimensions; } sub area { my ($self) = @_; $self->{width} * $self->{height}; } sub show_dimensions { my ($self) = @_; printf "height: %s, width: %s\n", $self->{height} || 'undef', $sel +f->{width} || ''; } package Square; use Moo; extends 'Rectangle'; sub area { my ($self) = @_; $self->{height} = $self->{width}; $self->SUPER::area(); } package main; my $rect = Rectangle->new(width => 2, height => 2); my $sq = Square->new(width => 2); $rect->demo; print "\n"; $sq->demo;
        Which outputs:
        Demo of Rectangle height: 2, width: 2 Resetting height => 4, width => 3 height: 4, width: 3 area: 12 height: 4, width: 3 Demo of Square height: undef, width: 2 Resetting height => 4, width => 3 height: 4, width: 3 area: 9 height: 3, width: 3
        The square fails as a stand-in for a rectangle. The is one of the reasons that wise man say Favor Composition Over Inheritance