Sid Burn

0. Overview

1. Inheritance is Bad: Code Reuse Part I
2. Inheritance is Bad: Code Reuse Part II
3. Inheritance is Bad: Code Reuse Part III

1. Introduction

There exists a legend named the Gordian Knot. It was a knot that nobody was able to untie. An oracle predicted that the one who will be able to untie the knot would become the king of Asia. A lot of people tried to untie it, but nobody was successful. It seemed like an impossible task to do. But 333 BC they came a man, when he tried to untie it he drew his sword, sliced the knot and untied it that way. That man was Alexander the Great, and became later the King of Asia.

In the first part i talked about inheritance and explained why inheritance is at so many levels broken to archive a good code re-usability. I introduced roles and explained how roles can be a lot better for code re-usability and a much cleaner design. I build an example in part II to show roles in action. And we still faced some problems. Code re-usability still seems not to be as good as wanted. We still needed to copy & paste some code. If you need the ability to change behaviour at runtime there is not an easy solution for that. You still can run in naming problems, because all properties/methods in a role needs to be unique in order to easily reuse and assemble then in a class. Now we want to resolve the remaining problems.

Probably, you now expect some awesome super feature. Something shiny new. Probably a new library? A Moose Extension? How can all that be easy possible? And if it is possible, it has to be very complex, not easy, right? The Answer is no. It is extremely simple. All we need are just classes, nothing more. Now you probably will not believe me. Just classes? No inheritance or multiple inheritance? No Roles? Just Classes? Yep, just classes, nothing more. You don't believe me? It's okay, i will show you.

2. Roles?

Before we start you probably now ask why did i created two long parts and explained roles with so much detail. If "Just Classes" should be the solution then everything before should not be important at all. The Answer is, no not all. The Parts before are really important to understand this chapter. The important part of the previous articles was not that we used roles. The important part was to understand how to "Design" everything. For example it is not important that Position is a role. It is important to understand that Position is a behaviour or a piece of code that should not be part directly in a class, the important part to understand was that Position needs to be a separated piece of code that we are able to reuse. And the exact same is true for Destroyable.

What you should do when you designing something is exactly that what we have done so far in Part I + II. But instead of roles, you create classes. Now you probably don't see why that should solve any problem we still have open. So lets start with something easy. With refactoring Position.

3. Position

In the previous Part i mentioned that i still don't liked that we duplicated Position and created PositionRW, but there seemed no other solution to do it otherwise. All other solutions looked even more worse. So now lets rewrite Position from a role to a class and lets what actually changed. Another thing is that instead of Position i name it Vector2, because a 2D/3D Vector is just the way how you usually save a position in a game. On Top of it i add methods to add/subtract vectors and let them return their magnitude (length). And im creating an immutable Vector2 so we already can implement the not changing position for our Building. The reason i add those extra methods is that it should be more reasonable to understand why we not want to copy Vector2 to a Vector2RW or something else dirty ways like we did with PositionRW.

package Vector2;
use Moose;

has 'x' => (
    is       => 'ro',
    isa      => 'Int',
    required => 1,
);

has 'y' => (
    is       => 'ro',
    isa      => 'Int',
    required => 1,
);

# Vector2 add(Vector2 vector)
sub add {
    my ( $self, $vector ) = @_;
    return Vector2->new(
        x => $self->x + $vector->x,
        y => $self->y + $vector->y,
    );
}

# Vector2 subtract(Vector2 vector)
sub subtract {
    my ( $self, $vector ) = @_;
    return Vector2->new(
        x => $self->x - $vector->x,
        y => $self->y - $vector->y,
    );
}

# float magnitude()
sub magnitude {
    my ( $self ) = @_;
    return sqrt($self->x ** 2 + $self->y ** 2)
}

Now we converted our Position role to a class and named it Vector2. We also added some methods. Now how does our Building class change?

package Building;
use Moose;
use Vector2;

with 'Destroyable';

has 'name' => (
    is       => 'rw',
    isa      => 'Str',
    required => 1,
);

has 'position' => (
    is       => 'ro',
    isa      => 'Vector2',
    required => 1,
);

sub info {
    my ( $obj ) = @_;

    my $alive = $obj->is_alive ? "true" : "false";
    return sprintf("[Building: Name=%s Position=%d/%d Life=%d/%d Alive=%s]\n", $obj->name, $obj->position->x, $obj->position->y, $obj->current_life, $obj->max_life, $alive);
}

Instead of a "with 'Position'" statement we added a propertie with the name "position" that is a type of our Vector2 class. Now think of it, what changed so far? Did we solve one of our problems already? The first problem that we solved so far is our naming problems. When you write a class you don't have to think about which methods other classes uses. In our example we could name our methods just add(), subtract() or magnitude(). But what would you have done if our Vector2 was still a role? Just naming methods like add or subtract would probably not be a good idea. You would probably name them add_position() or something else. But the main point here is that your class can't collide with another class. How you name your propertie in your Building class is up to you. And the methods from Vector2 don't get injected in our Building class. Nothing can collide.

That also eliminate another problem. If you build your classes that way you usually don't end with with classes that have hundreds of methods. You have your position that is a Vector2. And absolutly everything related to Vector2 is part of an Vector2 object. Makes sense, or? And that is in my opinion an important point. Even something simple like an Vector2 usually have a lot of methods. You often want methods like normalizing a Vector, calculating the distance between two vectors, doing a linear interpolation between two vectors and so on. You could sure add everything also to a Vector2 Role, but it will automatically always fill your class with a lot of garbage.

But let's rethink, one main point that i wanted to eliminate was the creation of PositionRW. How do we now do it without copy & pasting? Well, we already have done it. Our Unit class now looks something like that.

package Unit;
use Moose;

with 'Destroyable';

has 'name' => (
    is       => 'rw',
    isa      => 'Str',
    required => 1,
);

has 'position' => (
    is       => 'rw',
    isa      => 'Vector2',
    required => 1,
);

# void move_by(Vector2 vector)
sub move_by {
    my ( $self, $vector ) = @_;
    $self->position($self->position->add($vector));
    return;
}

sub info {
    my ( $obj ) = @_;

    my $alive = $obj->is_alive ? "true" : "false";
    return sprintf("[Unit: Name=%s Position=%d/%d Life=%d/%d Alive=%s]\n", $obj->name, $obj->position->x, $obj->position->y, $obj->current_life, $obj->max_life, $alive);
}

Now you probably feel cheated? But thats it. We already have a working Vector2. Nobody said that the object itself needs to be a mutable object. For our design it is absolutely fine to work with immutable objects. And if you want to allow that an object can move. No problem, instead of a "ro" propertie you just use a "rw" propertie. Job done.

We don't need to copy & paste code or some other ugly way. Do you remember in the second part that i mentioned that our role lock away our code and makes re-usability even more worse? Well that is exactly it. If you design it as a role you only can inject it in a class. But the code itself will become a part of the class. In this way we have an object of a class and pass it around. In my opinion that is really what "object orientation" is about. Having objects to work with. Not a bunch of properties and methods that get injected like you do it in procedural code. Here is another example of re-usability that now is easily solved.

Now our Unit can move, but in which direction does our Unit move? Now you probably want to save the "target position" in your class. How do you do it with our class? Well it is very easy. Just add another Vector2 propertie.

has 'target' => (
    is       => 'rw',
    isa      => 'Vector2',
    required => 0,
);

What have we done? Well we have reused Vector2. We now have two instances of it, one in position, another one in target in one class. Lets assume Vector2 would be a Role. How do you use two instances of a role in one class? With a class that is easy. But think of it. How do you have it done with a role? Creating another role? Copying Vector2 lets say to Target and rename addposition to addtarget and so on, and then inject Target in your class? Wouldn't that be just stupid?

Now you probably say. Okay everything is fine. What you have shown works with Position or a Vector. But that's not gonna work with everything, and we still had some problems left. But yes, it really works with everything. The reason for that is that you already think of behaviours. The thing with behaviours is that every behaviour is usable on its own, because you already separated it to a single logic unit. And you always can convert roles like that just to a class.

Destroyable class

So let's look at our Destroyable Role. We just convert it to a class. Its really simple.

package Destroyable;
use Moose;

has 'max' => (
    is       => 'ro',
    isa      => 'Int',
    required => 1,
);

has 'value' => (
    is       => 'ro',
    isa      => 'Int',
    writer   => '_set_value',
    required => 1,
);

has 'is_alive' => (
    is      => 'ro',
    isa     => 'Bool',
    lazy    => 1,
    builder => '_build_is_alive',
    writer  => '_set_is_alive',
);

sub _build_is_alive {
    my ( $self ) = @_;
    return $self->value > 0;
}

sub add {
    my ( $self, $amount ) = @_;
    my $max = $self->max;
    my $val = $self->value;
    if ( $val + $amount <= $max ) {
        $self->_set_value($val + $amount);
    }
    else {
        $self->_set_value($max);
    }
    return;
}

sub subtract {
    my ( $self, $amount ) = @_;
    my $min = 0;
    my $val = $self->value;
    if ( $val - $amount >= $min ) {
        $self->_set_value($val - $amount);
    }
    else {
        $self->_set_value(0);
        $self->_set_is_alive(0);
    }
    return;
}

There are not many changes to the Role. Instead of Moose::Role we just use Moose. I added a "require" statement to the properties, a builder for isalive. And i changed the name of some properties and methods. Instead of "maxlife" now it is just "max". "currentlife" => "value". Instead of "addlife" and "subtract_life" it is now just "add" and "subtract". This changes are now possible and good, because we have an class and later an object. There is no need to prefix/postfix values. But besides some naming changes it is nearly the same as the role. Now lets lock at our Building class how it will change.

package Building;
use Moose;
use Vector2;
use Destroyable;

has 'name' => (
    is       => 'rw',
    isa      => 'Str',
    required => 1,
);

has 'position' => (
    is       => 'ro',
    isa      => 'Vector2',
    required => 1,
);

has 'life' => (
    is       => 'ro',
    isa      => 'Destroyable',
    required => 1,
);

sub info {
    my ( $self ) = @_;

    my $life  = $self->life;
    my $alive = $life->is_alive ? "true" : "false";
    return sprintf("[Building: Name=%s Position=%d/%d Life=%d/%d Alive=%s]\n", $self->name, $self->position->x, $self->position->y, $life->value, $life->max, $alive);
}

We also can see here that we don't need anything special. Instead of injecting the Destroyable Role, we now have an attribute "life" that should be a Destroyable object. Now lets see some usage of our Building class.

my $hq = Building->new(
    name     => 'Headquarter',
    position => Vector2->new(x => 10, y => 10),
    life     => Destroyable->new(
        max   => 100,
        value => 100,
    ),
);

print $hq->info;
$hq->life->subtract(70);
print $hq->info;
$hq->life->subtract(70);
print $hq->info;
print $hq->position->magnitude, "\n";

Now our code itself doesn't change much. Instead of passing "maxlife", "currentlife" to our object, we now pass an object of Destroyable to our class. Instead of calling "$hq->subtract_life()" we now use "$hq->life->subtract(70)". In my opinion the later is much more cleaner. It is clear that you have an object that represents the life of our hq, and we can just call methods on our life to work with it. And once again you get better code re-usability because you can easily reuse Destroyable. Let's say every building also have some plasma shield that can absorb up to 50 damage. Once again it is easy. Just add an "shield" propertie of type Destroyable to your Building.

has 'shield' => (
    is       => 'ro',
    isa      => 'Destroyable',
    required => 1,
);

And your construction of $hp will change to this.

my $hq = Building->new(
    name     => 'Headquarter',
    position => Vector2->new(x => 10, y => 10),
    life     => Destroyable->new(
        max   => 100,
        value => 100,
    ),
    shield => Destroyable->new(
        max   => 50,
        value => 50,
    ),
);

Delegation

In my opinion something like "$hq->life->subtract(70)" is a clean interface. We directly see on the Top Level which objects we have, and we can operate on them. But for whatever reason some people want a "subtract_life()" method instead of calling "life->subtract()". If you also like to pollute your classes with a lot of garbage you also can do that easily with Delegation. For example you can change the Attributes in the Building class this way.

has 'life' => (
    is       => 'ro',
    isa      => 'Destroyable',
    required => 1,
    handles  => {
        'add_life'      => 'add',
        'subtract_life' => 'subtract',
    }
);

has 'shield' => (
    is       => 'ro',
    isa      => 'Destroyable',
    required => 1,
    handles  => {
        'add_shield'      => 'add',
        'subtract_shield' => 'subtract',
    }
);

The good part is as you can see here. You also can easily create "subtractlife" and "subtractshield" methods, without creating two roles. So you can still have your objects with hundreds of methods or properties without all that object chaining if that is something what you want. You can read more of it in Moose::Manual::Delegation.

Multiple Implementations

At the moment we had rewritten Destroyable to a class. But one problem what we didn't face so far is what i named "Multiple Implementation". What we wanted to do is to have multiple Destroyable implementations with different features. At best we want to separate every implementation and put it in their own file. But the important part was not separation alone. In our example we could just create a DestroyableResistances role if that was everything what we wanted. The important part was that we also can switch between the different implementations at runtime.

If you think about it. Switching the implementation is very easy. With our design all we have is just an object of class. If you just want to switch the implementation the only thing we need is to put another object in it. Or allow Moose another type. At the moment our definition for life in Building looks something like this.

has 'life' => (
    is       => 'ro',
    isa      => 'Destroyable',
    required => 1,
);

The first thing we need to change is make it "rw" to allow changing. The next is to change the "isa". We could for example change the isa to something like "Destroyable|DestroyableResistances". With a definition like this Moose will accept both classes. But that is still not a good way. The reason is we don't want to hardcode all our implementations in it. If you have 10 implementations and use in a lot of classes that is really a bad way. For example we also have our "shield" propertie und you need to add DestroyableResistances to it. And if you have other classes like Enemy, Unit, Dragon and so on that also needs a type or subtype of Destroyable you always have to name all classes that implements your behaviour, or change all entries whenever you add a new implementation. That is not a good way. We can fix that problem also easily, but at the moment for the sake of easiness we will change the isa value to "Object". Now Moose just ensure we got some Object. Later we will come back to this again and we will fix this. So our new life now should look something like that.

has 'life' => (
    is       => 'rw',
    isa      => 'Object',
    required => 1,
);

Lets assume we already had written our DestroyableResistances class. How can we now switch the implementation at runtime? Well it is really easy. We just create an object and assign it to life.

$hq->life(DestroyableResistances->new(...));

At some point that is so easy, it even sounds stupid to write about it, because it so obvious.

DestroyableResistances class

Now understanding how you can switch the implementation at runtime with easiness. Let's just write our DestroyableResistances implementation. The important part here is that we need the exact same interface. Only then we are able to switch objects without problems. Now lets look at our Destroyable class. Our Destroyable class had "max", "value" and "is_alive" as properties. And two methods named "add" and "subtract". When we now write our DestroyableResistances class we also need the exact same interface, to be able to switsch implementation without problems. But all that doesn't mean we can't have additional properties or methods. At least we write another implementation. In order to have a different behaviour we often have additional properties and the construction itself differs. But after that is done the class itself needs to behave the same. And the same means it needs the same properties, methods needs to take the same arguments and needs to return the same types. For example if our add/subtract would return a number, all other implementation also have to do it. But of course, the result itself can differ. And because it is another implementation it is also what we probably expect.

What we now want is a Destroyable implementation where it is possible to configure some Resistances. In the second part i talked about a dragon with fire damage and so on, but implementing this would mean we also have to implement types of damage, and we have to change some code to allow that. So for the sake of easiness i just implement a "global" resistance. Something like: We have 50% resistances. Now we only got half the damage. The amount of resistances should be changeable. To make the calculation easy our resistance is a number between 0 and 1. So 50% resistance is 0.5, 70% should be 0.3 and so on. So lets write our class.

package DestroyableResistances;
use Moose;

has 'max' => (
    is       => 'ro',
    isa      => 'Int',
    required => 1,
);

has 'value' => (
    is       => 'ro',
    isa      => 'Int',
    writer   => '_set_value',
    required => 1,
);

has 'is_alive' => (
    is      => 'ro',
    isa     => 'Bool',
    lazy    => 1,
    builder => '_build_is_alive',
    writer  => '_set_is_alive',
);

# Resistances as a value between 0 and 1
has 'resistances' => (
    is       => 'rw',
    isa      => 'Num',
    required => 1,
);

sub _build_is_alive {
    my ( $self ) = @_;
    return $self->value > 0;
}

sub add {
    my ( $self, $amount ) = @_;
    my $max = $self->max;
    my $val = $self->value;
    if ( $val + $amount <= $max ) {
        $self->_set_value($val + $amount);
    }
    else {
        $self->_set_value($max);
    }
    return;
}

sub subtract {
    my ( $self, $amount ) = @_;
    $amount = $amount * $self->resistances;
    my $min = 0;
    my $val = $self->value;
    if ( $val - $amount >= $min ) {
        $self->_set_value($val - $amount);
    }
    else {
        $self->_set_value(0);
        $self->_set_is_alive(0);
    }
    return;
}

What we now can do is something like this

my $hq = Building->new(
    name     => 'Headquarter',
    position => Vector2->new(x => 10, y => 10),
    life     => Destroyable->new(
        max   => 100,
        value => 100,
    )
);

print $hq->info;
$hq->life->subtract(50);
print $hq->info;

$hq->life(
    DestroyableResistances->new(
        max         => $hq->life->max,
        value       => $hq->life->value,
        resistances => 0.5,
    )
);

$hq->life->subtract(50);
print $hq->info;

The output of our application

[Building: Name=Headquarter Position=10/10 Life=100/100 Alive=true]
[Building: Name=Headquarter Position=10/10 Life=50/100 Alive=true]
[Building: Name=Headquarter Position=10/10 Life=25/100 Alive=true]

What we have seen so far is a second implementation of a Destroyable with resistances. At first our $hq starts with a simple Destroyable. We do 50 damage against it and our life sunk to 50/100. At runtime we changed the implementation to DestroyableResistances with 50% resistances. Another 50 damage now just reduced our life from 50/100 to 25/100. What we expected. The only proplem when you look at Destroyable and DestroyableResistances is, we have Code Duplication once again.

Refactoring Destroyable & DestroyableResistances

When you look at our classes then once again we see a lot of Code Duplication. Didn't i tell that with this way we can eliminate Code Duplication? Sure, you can, but that doesn't mean you automatically by magic get it. If you have Code Duplication you have to look at your code and try to abstract the Duplication. Now lets do it.

At first, what is Code Duplication anyway, and how do we abstract it? At first we have a specific interface that we always need. So the existence of some specific properties or methods itself is not Code Duplication. They have to be there to full fill our interface. But if you have classes that always needs the same properties over and over again or you have properties that together build a "unit" then you should try to abstract it away. In our Destroyable class you already see that king. Look at the attribute "max" and "value". Which purpose do have "max" alone? If you think about it, max is the limit for "value". Sure you can have "value" alone but in this case we need max to specify the maximum possible value for "value". So we should try to abstract that.

Another way to find what you need to abstract away is if you look at the code of your methods. Which code exists in both classes and analyse what they do. If you look at both classes, well there are almost identical. In the add() method we add a value to "value", and then we try to ensure that our "max" is not reached. In "subtract" we do the same, but ensure our minimum value here 0 is not reached. So what we do is to ensure our "value" is always in a range. Why not abstract it away? Let's create a MinMaxValue class.

package MinMaxValue;
use Moose;

# We want:
# MinMaxValue->new(Num max, Num value)
# MinMaxValue->new(Num max, Num value, Num min)
around BUILDARGS => sub {
    my $orig  = shift;
    my $class = shift;

    if ( @_ == 2 || @_ == 3 ) {
        my $max   = shift;
        my $value = shift;
        my $min   = shift // 0;

        return $class->$orig(max => $max, value => $value, min => $min);
    }
    else {
        return $class->$orig(@_);
    }
};

has 'max' => (
    is       => 'rw',
    isa      => 'Num',
    required => 1,
);

has 'min' => (
    is       => 'rw',
    isa      => 'Num',
    default  => 0,
    required => 0,
);

has 'value' => (
    is       => 'rw',
    isa      => 'Num',
    required => 1,
    trigger  => \&_check_min_max,
    reader   => 'get',
    writer   => 'set',
);

sub add {
    my ( $self, $amount ) = @_;
    $self->set($self->get + $amount);
    $self->_check_min_max;
    return;
}

sub subtract {
    my ( $self, $amount ) = @_;
    $self->set($self->get - $amount);
    $self->_check_min_max;
    return;
}

sub _check_min_max {
    my ( $self ) = @_;
    if ( $self->get > $self->max ) {
        $self->set($self->max);
    }
    if ( $self->get < $self->min ) {
        $self->set($self->min);
    }
    return;
}

Our Destroyable class now looks like this

package Destroyable;
use Moose;
use MinMaxValue;

# We want:
# Destroyable->new(max => 100, value => 100)
around BUILDARGS => sub {
    my $orig  = shift;
    my $class = shift;
    my %args  = @_;

    $args{value} = MinMaxValue->new($args{max}, $args{value}, 0);

    $class->$orig(%args);
};

has 'value' => (
    is       => 'ro',
    isa      => 'MinMaxValue',
    required => 1,
);

has 'is_alive' => (
    is       => 'ro',
    isa      => 'Bool',
    init_arg => undef,
    lazy     => 1,
    builder  => '_build_is_alive',
    writer   => '_set_is_alive',
);

sub _build_is_alive {
    my ( $self ) = @_;
    return $self->value > 0;
}

sub add {
    my ( $self, $amount ) = @_;
    $self->value->add($amount);
    $self->_check_alive;
    return;
}

sub subtract {
    my ( $self, $amount ) = @_;
    $self->value->subtract($amount);
    $self->_check_alive;
    return;
}

sub _check_alive {
    my ( $self ) = @_;
    if ( $self->value <= $self->value->min ) {
        $self->is_alive(0);
    }
}

And our DestroyableResistances like this

package DestroyableResistances;
use Moose;
use MinMaxValue;

# We want:
# Destroyable->new(max => 100, value => 100, resistances => 0.5)
around BUILDARGS => sub {
    my $orig  = shift;
    my $class = shift;
    my %args  = @_;

    $args{value}       = MinMaxValue->new($args{max}, $args{value}, 0);
    $args{resistances} = MinMaxValue->new(1, $args{resistances}, 0);

    $class->$orig(%args);
};

has 'value' => (
    is       => 'ro',
    isa      => 'MinMaxValue',
    required => 1,
);

has 'resistances' => (
    is       => 'ro',
    isa      => 'MinMaxValue',
    required => 1,
);

has 'is_alive' => (
    is       => 'ro',
    isa      => 'Bool',
    init_arg => undef,
    lazy     => 1,
    builder  => '_build_is_alive',
    writer   => '_set_is_alive',
);

sub _build_is_alive {
    my ( $self ) = @_;
    return $self->value > 0;
}

sub add {
    my ( $self, $amount ) = @_;
    $self->value->add($amount);
    $self->_check_alive;
    return;
}

sub subtract {
    my ( $self, $amount ) = @_;
    $self->value->subtract($amount * $self->resistances->get);
    $self->_check_alive;
    return;
}

sub _check_alive {
    my ( $self ) = @_;
    if ( $self->value <= $self->value->min ) {
        $self->is_alive(0);
    }
}

Now we reduced some Code Duplication. Instead of always checking if our value rechead the maximum or minimum we now have a separated MinMaxValue that does that. So we don't need this code in our methods anymore. But our Destroyable class also needs to check if our object is alive. The only thing we added in Destroyable is just a check when our MinMaxValue hits 0. If it hits zero is_alive will be set to a false value. If you look at it our Destroyable consumes a MinMaxValue and just add some extra functionality to it. At some way, it is like inheritance. With inheritance you would probably create a class named Destroyable inherit from MinMaxValue and you would add your specific code.

Now this example probably looks a little bit more complicated. Instead of inherit from it, we embed another class/object. The benefit is we don't run in any problems that we usaly got with inheritance (Look at Part I if you forgot). You can embed as many objects like you want. You don't run in naming problems and a lot of other stuff.

But now let's focus on DestroyableResistances. Through abstracting and creating MinMaxValue you already see that we also re-used this class for our resistances and we already benefit of it of abstracting it away. But if you still look at aour DestroyableResistances it still feels a little bit like Duplicated Code. Can we further abstract something away? Yes, sure. Destroyable already was a class that uses our MinMaxValue and added something to it. But now look at our DestroyableResistances. Our Resistances works the same way like Destroyable, the only thing DestroyableResistances does is to add another MinMaxValue to it, and change the subtracting. So, we do we not embed Destroyable in DestroyableResistances? Now let's name it DestroyableResistances2.

package DestroyableResistances2;
use Moose;
use Destroyable;
use MinMaxValue;

# We want:
# Destroyable->new(max => 100, value => 100, resistances => 0.5)
around BUILDARGS => sub {
    my $orig  = shift;
    my $class = shift;
    my %args  = @_;

    # Creating _destroyable
    my $max   = delete $args{max};
    my $value = delete $args{value};
    $args{_destroyable} = Destroyable->new(max => $max, value => $value);

    # Creating resistances
    $args{resistances} = MinMaxValue->new(1, $args{resistances}, 0);

    $class->$orig(%args);
};

has '_destroyable' => (
    is       => 'ro',
    isa      => 'Destroyable',
    required => 1,
    handles  => [qw(value is_alive add)],
);

has 'resistances' => (
    is       => 'ro',
    isa      => 'MinMaxValue',
    required => 1,
);

sub subtract {
    my ( $self, $amount ) = @_;
    $amount = $amount * $self->resistances->get;
    $self->_destroyable->subtract($amount);
    return;
}

At first, in BUILDARGS we change the constructor in a way that it accepts the same signature like DestroyableResistances. It will build the needed Destroyable class for us. If you didn't pay attention i already did some similar changes in Destroyable or the MinMaxValue class.

But now our class is really short. We just needed to add a resistances propertie. We suplied our subtract method that should be changed. The rest of the needed methods will just be delegates to our Destroyable object.

Now lets quickly check if both implementations really do the same work.

my $hqr1 = Building->new(
    name     => 'Headquarter1',
    position => Vector2->new(x => 10, y => 10),
    life     => DestroyableResistances->new(
        max         => 100,
        value       => 100,
        resistances => 0.5,
    ),
);

my $hqr2 = Building->new(
    name     => 'Headquarter2',
    position => Vector2->new(x => 10, y => 10),
    life     => DestroyableResistances2->new(
        max         => 100,
        value       => 100,
        resistances => 0.5,
    ),
);

print $hqr1->info;
print $hqr2->info;

$hqr1->life->subtract(50);
$hqr2->life->subtract(50);

if ( $hqr1->life->value->get == $hqr2->life->value->get ) {
    print "The same\n";
}
else {
    print "Not the same\n";
}

print $hqr1->info;
print $hqr2->info;

We will get the following output

[Building: Name=Headquarter1 Position=10/10 Life=100/100 Alive=true]
[Building: Name=Headquarter2 Position=10/10 Life=100/100 Alive=true]
The same
[Building: Name=Headquarter1 Position=10/10 Life=75/100 Alive=true]
[Building: Name=Headquarter2 Position=10/10 Life=75/100 Alive=true]

Shortly, yes we are done.

Conclusion

What you have seen so far is nothing new. The technique itself is called "Composition". Probably you sometimes heard the statement "Composition over Inheritance". In my opinion, Composition is the most powerful/important way how you can/should program in a object oriented language. It is much more powerful then inheritance. It is a shame that so many books, tutorials and so on just focus on inheritance, sometimes you read a side-node in books that there exists Composition (and Aggregation) but then you get hundreds of sides just explaining how inheritance work.

But okay, historically there exists a small reason for it. The whole last part what i often called "Multiple Implementations" is only really possible with Interfaces. Well not directly, you also can use multiple inheritance to simulate interfaces, like you also can simulate roles with multiple inheritance. So "Interfaces" was one attempt to force users in languages like Java or C# more to the pattern what i described here. More to Composition. The problem was that still everyone just talked about inheritance, because these languages still supported single-inheritance. The end of the story is that most people don't knew what's the point of an interfaces because an interface itself seems to do absolutely nothing at all.

But in fact, interfaces are probably one of the most important "new" features in object oriented programming. Well not directly in Perl, because Perl has no type system, and no methods signature or return types and so on. And variables can hold any type, so in Perl you don't really need them. But the important part here is the concept that interfaces tried to introduce. Roles also tries to introduce a concept to achieve better code re-usability. In fact there are a lot better than inheritance, and if you never used them, you should use them. But roles are still not as useful as composition + interfaces. In reality roles are more a rip-off of interfaces. Roles try to make interfaces usable, without understanding what interfaces really are.

At the moment i highly recommend to read more about Composition and interfaces and try to understand them. If you already have used roles, try to convert them to classes. If you see Code Duplication like explained before, try to abstract it away in another re-usable class. Often you get a much higher re-usablity you didn't even expect. For example, did you ever expected to use two instances of Destroyable in a single class? In Part II you could inject the Destroyable role into a class, but with a class you just can have easily two properties of Destroyable. And if you forgot, i just added a "shield" to our Building. How did you have done it with a role? Probably creating a "Shield" role, even if it would just do the exact same like Destroyable?

Roles also can't "embed" other roles. But with a class that's not a problem. A MinMaxValue class used in a Destroyable class. A Destroyable class embedded in a DestroyableResistances class and so on. With composition you really start to create classes with a very high abstraction. And often because you separate a lot of code, your code really gets easy/small. You nearly ever see big classes. And you often implement new features really fast because you already have a lot of reusable classes.

If you now have questions then feel free to ask, at the moment i'm not planning a fourth part. But if i'm doing a fourth Part it will just be some more information about Interfaces and explaining why they are so important, and probably answering some question if they take a little bit longer to explain.

0. Overview

1. Inheritance is Bad: Code Reuse Part I
2. Inheritance is Bad: Code Reuse Part II
3. Inheritance is Bad: Code Reuse Part III

1. Introduction

My first part about Inheritance was more theory. I explained the problems with Inheritance, and explained how roles can solve some of them. I told that there is even a better way, but instead of going straight to that point i want to first talk about Roles. We first need to understand Roles and which problems Roles still have to go further. Instead of just explaining the problems in theory i also want to add some code, because code always helps a little bit more to understand the problem. So that post even got a little bit longer than i really wanted.

2. Our example

To point out the problems with Roles we should create a little example.

In this example i want to create two classes of a game. In that game i should be able to define Buildings and Units. Every Building in the game has a name, can be destroyed and have a position. The exact same goes for a unit. The only difference is that the position of a building is not changeable, but a unit can easily move and change his position.

Lets just quickly talk about inheritance. I hope from the first post that using inheritance is not a good way. Yes you can solve the problem if you start inherit from one or the other things. But you later will run in the problems that described in Part I. If you read Part I and still don't see why inheritance would be a bad way to solve please just comment.

3. Behaviours

At first lets think which behaviours we need to implement as Roles. The best way how to do it is to just try to implement a class. At best is to start with the smallest classes. The reason is that you you have implement them fast and you already get some Roles that you can reuse in some bigger classes.

Well here we just have Building and Unit. But Building has an immutable Position so we start with the Building class. Well the Building class was already defined well. We have a name, it is Destroyable and it has a position. So we can think of 3 Behaviours/Roles "Name", "Destroyable" and "Position".

4. "Name" Role?

Lets think of the name. Well it really depends if you really create a behaviour out of it.

In our game we just set or get the name. It is just a single string propertie and thats it. So even if nearly every class have a name, it doesn't make too much sense to create a role out of it. But if in your application you have a lot of methods associated with "name" then you should definitly create a role. As soon as you hit 2 properties it usaly makes sense to create a role.

Even with one propertie you can argue that this should be role. Because adding a role is still less code. And if you already can think of additions to the "name" propertie that every class with a "name" should have you can directly start with a role. So creating a role even for a single propertie is not wrong. But in that case i really can think of anything special or what i want to add. I will just set/get the name and that's it. So i implement "name" just as a simple propertie in every class.

5. Destroyable Role?

Now "Destroying" starts to get a little bit more complex. In order to destroy something we need a way to express "life". What i use is just an integer for that. When our integer gets to 0 our Building is destroyed. But we also want a start value or better a maximum value. That is important because that means we need to ensure that the value not be less 0 or more than our maximum value.

So just having a "life" propertie that's just an integer and can directly be changed is not a good way. Instead we should create a role with a current value propertie. A proertie that defines the maximum, and some helper properties. For example a boolean that just return true/false if our Building is still alive or not.

We also should define "ro" properties not "rw" properties. Actually defining "ro" properties doesn't mean we create immutable classes/roles. In my case what i want to exporess is that a user is not allowed to change that value directly. But you still can provide methods that change the value. For example currentlife. If you allow a user to directly change currentlife he could set the value lets say to 120 or -10 even if 100 was the maximum allowed value, and the value should never go under 0.

Instead we enforce that the user have to call addlife() or subtractlife() if he wants to change the life. And those methods ensure the correctness of the current_life propertie.

So we create a behavior named "Destroyable". This behaviour will look something like this.

Role: Destroyable
  - int max_life
  - int current_life
  - bool is_alive
  - void add_life(int x)
  - void subtract_life(int x)

In code that Role above can look something like this:

package Destroyable;
use Moose::Role;

has 'max_life' => (
    is  => 'ro',
    isa => 'Int'
);

has 'current_life' => (
    is     => 'ro',
    isa    => 'Int',
    writer => '_set_current_life',
);

has 'is_alive' => (
    is      => 'ro',
    isa     => 'Bool',
    default => 1,
    writer  => '_set_is_alive',
);

sub add_life {
    my ( $self, $amount ) = @_;
    my $max = $self->max_life;
    my $cur = $self->current_life;
    if ( $cur + $amount <= $max ) {
        $self->_set_current_life($cur + $amount);
    }
    else {
        $self->_set_current_life($max);
    }
    return;
}

sub subtract_life {
    my ( $self, $amount ) = @_;
    my $min = 0;
    my $cur = $self->current_life;
    if ( $cur - $amount >= $min ) {
        $self->_set_current_life($cur - $amount);
    }
    else {
        $self->_set_current_life(0);
        $self->_set_is_alive(0);
    }
    return;
}

Now we have a "Destroyable" Role that can be reused in a lot of classes.

6. Position Role

The last thing we need for our Building is a "Position" Role or behaviour. Let's assume we have a 2D game and the position are just integer numbers. The only thing we need are X and Y coordinates. Does it make sense to create a role out of it for just 2 properties?

Well yes, even if the coordinate is just expressed with a single propertie (for example a 2D Vector) it makes sense to do it. The difference between the name where we didn't do that is if we can think of the position as more as just a single value.

And we already thought about a unit that has a position that can be moved. So it could make sense in the future to add some methods to it. But we could also add a lot of other helper methods to it or change the way how position works. For example we really write a Vector2 class, but still has an x and y value, or methods that transform our positions to other types and so on.

So now we have a simple Position Role like this.

package Position;
use Moose::Role;

has 'x' => (
    is  => 'rw',
    isa => 'Int',
);

has 'y' => (
    is  => 'rw',
    isa => 'Int',
);

7. Building class

Now we have everything for our Building class that is really small and look like this.

package Building;
use Moose;

with 'Destroyable';
with 'Position';

has 'name' => (
    is  => 'rw',
    isa => 'Str',
);

sub info {
    my ( $obj ) = @_;

    my $alive = $obj->is_alive ? "true" : "false";
    return sprintf("[Building: Name=%s Position=%d/%d Life=%d/%d Alive=%s]\n", $obj->name, $obj->x, $obj->y, $obj->current_life, $obj->max_life, $alive);
}

I also added a info() method to it that represents the current state of out object in a string. Now we can write code like this.

my $hq = Building->new(
    name         => 'Headquarter',
    max_life     => 100,
    current_life => 100,
    x            => 10,
    y            => 10,
);

print $hq->info;
$hq->subtract_life(70);
print $hq->info;
$hq->subtract_life(70);
print $hq->info;

8. Unit class

The reason why we created Behaviours/Roles was to ensure we could reuse our code. Now let us think of our Unity class. The unity class can do exactly what the Building class can do, the only thing that change is that the position can change. So what we now can do is create a "Unit" class and add the "Destroyable" role to it again. But what is with Position?

Now we face one Problem. We have written code for Position, even if it is not big at the moment it correctly represents a Position. But at the moment the x/y values are read-only. That is also correct because we wanted a Position that can not be changed. Our building should not be able to move.

If we start to change the Position role and we change x/y to "rw" we have the problem that also Buildings can change there position and we don't want that to happen.

We could also let x and y be "ro" and add some methods that changes the Position. And than add a propertie where we can configure if position can change or not. But in my opinion. That solution is even more worse, it is exactly one of the same problems we got with inheritance. The thing is. If we add a role like "Position" and it has some methods in it, we should be able to call it, and write code that disables the methods. Its just an evil workaround to do that. Than you also can switch back to inheritance and or your booleans there to activate/deactivate methods, you literally have nothing won if you start using workarounds like that. Because the whole point of roles was that you only add to a class what matters, and you can freely reuse pieces without restrictions like an inheritance tree.

If we really think of it, the only way how it seems we could do it "right" is to duplicate some code. So we will write another Position Role. But this time x/y can be changed. We still make x/y "ro" attributes, but we provide some methods to change it. Lets name the class PositionRW

package PositionRW;
use Moose::Role;

has 'x' => (
    is     => 'ro',
    isa    => 'Int',
    writer => '_set_x',
);

has 'y' => (
    is     => 'ro',
    isa    => 'Int',
    writer => '_set_y',
);

sub move_by {
    my ( $self, $x, $y ) = @_;
    $self->_set_x($self->x + $x);
    $self->_set_y($self->y + $y);
}

And now our Unit class looks something like this

package Unit;
use Moose;

with 'Destroyable';
with 'PositionRW';

has 'name' => (
    is  => 'rw',
    isa => 'Str',
);

sub info {
    my ( $obj ) = @_;

    my $alive = $obj->is_alive ? "true" : "false";
    return sprintf("[Unit: Name=%s Position=%d/%d Life=%d/%d Alive=%s]\n", $obj->name, $obj->x, $obj->y, $obj->current_life, $obj->max_life, $alive);
}

If we write code like this:

my $hq = Building->new(
    name         => 'Headquarter',
    max_life     => 100,
    current_life => 100,
    x            => 10,
    y            => 10,
);

print $hq->info;
$hq->subtract_life(70);
print $hq->info;
$hq->subtract_life(70);
print $hq->info;


my $unit = Unit->new(
    name         => "Hero",
    max_life     => 100,
    current_life => 100,
    x            => 20,
    y            => 20,
);
$unit->add_life(20);
$unit->subtract_life(50);
$unit->move_by(5, 10);
print $unit->info;

We get this output

[Building: Name=Headquarter Position=10/10 Life=100/100 Alive=true]
[Building: Name=Headquarter Position=10/10 Life=30/100 Alive=true]
[Building: Name=Headquarter Position=10/10 Life=0/100 Alive=false]
[Unit: Name=Hero Position=25/30 Life=50/100 Alive=true]

So everything works. We now have our Behaviours. The behaviours are reusable. We have a Position class that is immutable and an immutable Position class. Our Unit class is a really good example how we reused only that code what we needed. So is everything good and are we in heaven?

9. Problems with Roles

Now lets rethink, do we have any problems in our code so far? At first lets talk about what a "problem" is. Sure our code works exactly like we wanted. We have a good Code Reuse. But in my opinion our Code Reuse is not good enough.

And you see that Problem with the PositionRW Role. Well the problem is not that we have a PositionRW Role. To have two Roles like that is absolutly fine, as long as there implementation differs. In that case we have a Position that is immutable. And PositionRW is also a position, but it is a mutable Position. Both are Positions, but they have a different implementation.

So having two roles for two different positions is okay. But what is annoying is that we literaly duplicate code. Well in that example its just 2 properties x and y, but it is still annoying that we have to do that. It is not important here that there are just 4 lines of code. Lets think further. What would be if we also implemented 5 helper methods? Well we also would copy all Methods from Position to PositionRW because PositionRW has the exact same functionality. Or what is if we want to add a method or later change a method because some had a bug? Well you will run in the problems that you usally get through duplicated code.

If you now think that inheritance could probably help you. Not really. I don't knew exactly at the moment if Moose lets you redefine a propertie from 'ro' to 'rw' in a subclass. But even if it allows that, i would never recommend that. You will break the rules in the Liskov Substituation Principle (that will be another blog post) that even will create a greater mess.

And often someone uses 'ro' because of thw reasons i explained before. To ensure that the object is always in a correct state. Changing a property from 'ro' to 'rw' means that methods could be wrong, for example because you created lazy methods that just calculate the value once, because well the value never changes or when it changes through an allowed method then you reset your cache. There are ways how you program everything that it still can work even with a 'rw' propertie. But if someone did that he would not have set the propertie set to 'ro'. Using 'ro' properties usally means you make your life easier, because you don't allow changing or just through your supported methods that can handle with that.

If you start with 'rw' and inherit and change it to 'ro' then you have the same problem like already mentioned. Code that was to suppose to change a value will now throw errors if you execute them. That is just a crazy design if you work in such a system. Because you never knew if when a error is thrown because something is wrong, or something got disabled. And actually makes it even right that there is thrown an error. You should make everything simple. If you are not allowed to change something it should be 'ro' and you should not have a method that can change it, but throws exception when you try executing them. It's just an insane design.

But how can we describe our problem in words? Well i name it "Multiple implementations". So what does "Multiple Implemenation" means? In our case we have two different Positions. One should be immutable, the other mutable. In such cases you often have some code that overlaps. But even if there is something that overlaps it would be great if we could still avoid Code Duplication as much as possible.

The problem here is. Role itself doesn't helps use with Multiple Implementations at all. In fact Roles makes it even more worse. Because your code is locked in a Role that can't be used directly. You only can apply a role to a class, and then use that class.

To better describe Multiple Implementation lets look at another example. Lets relook at our Destroyable Role. The role itself works like wanted. But lets assume we wanted to add a Dragon. Now our Dragon does fire damage. But wouldn't it be stupid if a dragon could be beaten by fire? Well yes, i think so, so i want to add that dragon in my game and make it immun to fire. But how do i do it?

So everything that can be damaged gets the Destroyable Role. To allow our dragon to be immung against fire we need to change the way how Destroyable works. We could for example invent a DestroyableResistances Role. In that role we can for example fire resistances, and our Dragon then becomes 100% fire resistances. The problem if we do it, you will see that a lot of your code will overlap. You probably just start with copy Destroyable.pm to DestroyableResistances.pm and start to change your code.

I hope that it is now understandable what i mean with "Multiple implementations", and that Roles still can't help you in such a case.

And now you say to me. Okay, but i can change Destroyable and add Resistances to it, right? Well sure, you can do it. And if you want to add another feature you also can add it to Destroyable. And another feature, and another feature, and... and later you end up again with a class 1000 lines long that has nearly every feature build in. And how do you configure which feature is active or deactivated? Well probably again with some boolean values?

You do not learn, or do you?

But here comes another problem. Lets assume you decided to create different Roles. Now you have your Destroyable Role for Buildings. Your Dragon gets your shiny new DestroyableResistances Role. You now think. "Yes we have Code Duplication, but i accept it". It isn't much and the design is much cleaner then having one big class with every feature in it. Okay that is fine, but suddenly your Game Designer comes to you. He wants you to add something new. A Hero class. So what is special about your Hero class? The Hero class starts with no special. But when it hits level 2 the player can choose if he wants two different armors. The first Armor gives the user 50% fire Resistances, and the second armor heals every friendly unit around the hero when our hero gets damage.

And now you are stuck. You Hero starts with your Destroyable Role. Well you already have a DestroyableResistances role, but you can't change a role at runtime. And even special, not just change the role in the class, you need to change the behaviour from Destroyable to DestroyableResitances at runtime just for a specific object, not for the whole class. Okay, maybe you just start with DestroyableResistances and set resistances to 0% to emulate a normal Destroyable role. But how do you implement the healing? That's a new feature. Creating a DestroyableHealing Role is possible but you can't change from DestroyableResistances to DestroyableHealing.

Will you probably once again throw the different roles away and just stick to your DestroyableThatDoesEverything role? That good old role with 2000 lines of code where all different 16 hit mechanics that evolved over time is now included?

The next problem that roles don't solveare that shiny big objects. Objects where you look at and getting 200 properties/methods. Often you get it from objects that use inheritance. It just inherit from one class, that inherit from another class and so on. And later you have your high level class that has so much methods and properties that it takes forever to understand what that class can do.

And if that is not enough, there is still another problem. All your properties and methods you define can be considered as "global". If you want to add a role to your class, then the role can conflict with another role. For example you have an "Add" Method in Role1 and an "Add" method in Role2. Then you get problems. You can't just add both functions. And that can create serious problems. If you have that in mind it means that you have to pick the names of all your properties and methods wisely as if they were global. Because if you don't do that, you can't reuse your code. And once again its the same problem with inheritance. If you inherit from another class you also need to look that you don't overwrite a method accidental. You have to name every new method unique.

10. Next Part

To finish this part, in my opinion roles are by far better than inheritance. It is just a cleaner design and you achieve code re-usability more easily. But there are still some problems with Roles. If you need Multiple Implementations then roles don't help you at all with code re-usability. Either way you still start to copy & paste your code into new similar roles. Or you start writing your big roles that does everything with a lot of booleans to decide what to do. And that was exactly where you end usually with single-inheritance and was one reason for roles. To pick everything into behaviour and just add to a class what it really needs, instead of depending on a lot of state variables, that makes everything more complex.

So in the next part i will describe a way how you can also eliminate the remaining problems. How you can write multiple implementations. Switch those easily at runtime. How you don't run in naming problems, and how to design objects that are easy to understand without hundreds of properties/methods and you achieve an even better code re-usability.

0. Overview

1. Inheritance is Bad: Code Reuse Part I
2. Inheritance is Bad: Code Reuse Part II
3. Inheritance is Bad: Code Reuse Part III

1. Introduction

A little time ago i commented on a blog on this site and gave an description about why Roles are better than inheritance. Or better, w…

The first thing i wanted to talk about is the map, grep and sort Functions. I think these functions are somewhat special. If someone look at these functions then we can say that these are concepts of a functional programming language.

All three functions take a code block. All three functions then goes through a list and uses that function to do specific thinks. "map" apply's a function to every element and returns a new list. "grep" uses the code block to specify a filter function. And with "sort" you can sort the list however you like it.

When i programmed in Perl i often used these functions. Some people probably hate them because they are hard to read and don't understand them at all. I think if you understood it once it really gets easier to read them, but the excessive use of "symbols" and that you have to read them from down to up still makes them harder to read as they should.

But now i am programming in C#, and at first it seemed that C# didn't had anything like map/grep/sort. But well just at the first look. Later someone will probably find LINQ that gives you an implementation like map/grep/sort in C#. And at the first look, it didn't seem so much different. It looks nearly the same.

As an example. You have an array of ints in Perl and you only want every number lower than 5. You will write something like this.

my @ints = ( 1, 2, 8, 3, 6, 7, 12, 3 );
my @low5 = grep { $_ <= 5 } @ints;

In C# it looks something like this

var ints = new int[] { 1, 2, 8, 3, 6, 7, 12, 3 };
var low5 = int5.Where(e => e <= 5).ToArray();

It looks nearly the same. The only thing to understand is what is the meaning of "e => e <= 5". That is called an Lambda-Expression, and what it does is absolutely the same as defining an anonymous function. Well i already seen a lot of people in the C# world that calls that the "Special LINQ-Syntax" because there think it is special to LINQ, but it is not. You can use them everywhere. Here Where() is just a method that takes an anonymous function. In Perl or JavaScript it would look something like this.

sub { my ($e) = @_; $e <= 5 }
function(e) { return e <= 5 }

So absolutely nothing special, right? Well, not directly the difference start to point out if you use more complex examples. Let's take the Schwartzian Transformation in Perl

@unsorted = ( "aaaa", "a", "aa" );
@sorted = map  { $_->[0] }
          sort { $a->[1] <=> $b->[1] }
          map  { [$_, length($_)] }
              @unsorted;

It sortes the words basend on there length. So @sorted will be "a", "aa", "aaaa" in the end. Now in C#

var unsorted = new string[] { "aaaa", "a", "aa" };
var sorted   = unsorted
    .Select(word => new { word, word.Length })
    .OrderBy(t => t.Length)
    .Select(t => t.word)
    .ToArray();

Well, i think it is by far better readable. The first thing. You can read it from up to down. And the next thing. Because of the better way to define Anonymous Functions with named parameter it is by far better readable than those "$_->[0]" or "$a->[1]" examples. Even if you don't knew anything about LINQ or Anonymous Functions. You don't need to be a genius to guess what "OrderBy(t => t.Length)" does. Probably Ordering by length? Yes!

But okay, there exists really a special LINQ Syntax. Because you could even write the above example as something like this in C#

var sorted = 
    from word in unsorted
    let length = word.Length
    orderby length
    select word;

So how is it now with readability? What do you think the following C# LINQ Example will output

string[] strings = {
    "A penny saved is a penny earned.",
    "The early bird catches the worm.",
    "The pen is mightier than the sword." 
};

var earlyBirdQuery =
    from sentence in strings
    let words = sentence.Split(' ')
    from word in words
    let w = word.ToLower()
    where w[0] == 'a' || w[0] == 'e'
        || w[0] == 'i' || w[0] == 'o'
        || w[0] == 'u'
    select word;

And this is just the beginning. Because LINQ have Functions for the most words that you already knew from SQL. Contains, First, GroupBy, Join, OrderBy, Union, Where, Any, Count, Min, Max and a lot more LINQ Queries can be really readable.

But i think that is still not the important part. What makes the difference is that all this is implemented as Iterators. So it only needs enough memory to calculate the next entry. You can even have an LINQ expression that reads TeraBytes from Data from Disk and it will still work. But even this is not the most important part. LINQ is just an interface and you can do a lot of different things with it. For example there exists LINQ to XML. So you can use LINQ to extract Data from XML. There also exists LINQ to SQL that creates SQL Queries from the LINQ expressions.

And on Top of that there also exists PLINQ. So what does the "P" stands for? It stands for "Parellel". But PLINQ just add one Method. You just have to add an ".AsParallel()" to the query and it automatically executes everything after it in multiple Threads so that all your CPU Processors will be used. Really nice, or?

So i think LINQ is extremely awesome. But there is one thing that bother me the most. Everything what you see about LINQ was only possible with the release of C# 3.0 that released around 2007. The C# development team needed to add a lot of functionality in C# that something like LINQ would be possible in C#. But Perl on the other side already had all that features since 1994 when Perl 5 released. So, why don't we have something like LINQ in Perl? I mean we have an excellent Book like "Higher Order Perl" that explains Functional Programming in Perl. That book teaches you everything that you need to knew to implement your own LINQ in Perl. And yet, nobody ever thought about it. Why?

I think the reason is that we already had map, sort and grep directly built into Perl. Absolutely nobody thought about wrapping it in objects and wrapping it in iterators. Why should someone do it? Because on the surface it looks as if you want to rebuild something that is already implemented in the language and it has no benefit at all. We already thought it was perfect. And thinking that something is perfect also means it is an dead end.

Hello,

so now i did it. I registered to write about Perl. But actually i wonder myself why i did it now, and not earlier. So i want to tell a little bit about myself.

I'm 31 years old. I come from germany so you probably notice that my english is not the best. I apologize and try to improve it. I started programming when i was 13-15 years old. I don't really knew anymore when i exactly began. My first programing language that i learned was C. And actually i somewhat hated that language. After that i also learned C++, did some programming in Visual C++, Visual Basic and probabl…