Delegation, composition and aggregation

nrg_alpha

Ok, so I was looking through the GoF Design Patterns book at the store (can't afford to pick it up at the moment - so every once in a while, I go back and read more).

"Favor object composition over class inheritence"

Fair enough.. it explains the pitfalls of inheritence (implementation being bound to compile-time, 'breakage' of encapsulation, tight coupling (thus changes = propogation change issues) etc..

I understand composition (if the 'owner / container' object is destroyed, composite objects go with it). But I'm hazy on delegation and aggregation (not so much from a definition stand point, but from a PHP coding standpoint).

So for example:

class floor {
    private $obj;
    function __construct(){
	$this->obj = new rectangle;
    }

function computeArea($x, $y){
return $this->obj->Area($x, $y);
}
}

class rectangle{
    private $width, $height;
    function Area($a, $b){
	$this->width = $a;
	$this->height = $b;
	return $this->width * $this->height;
    }
}

$objTiles = new floor;
echo $objTiles->computeArea(3,5);

How would this composition example be rewritten as deligation and another for aggregation instead?

laserlight

nrg_alpha wrote:
How would this composition example be rewritten as deligation and another for aggregation instead?

You already involve delegation: the floor class delegates the task of computing area to its $obj data member's Area() method. Aggregation is a weaker form of composition, so you already have aggregation.

nrg_alpha

Hmmm.. I figured this example was a composition (if I destroy the object $objTiles, the object $obj is destroyed with it). Perhaps then I'm misunderstanding things somewhat (as my understanding was delegation as tapping into the method of a separate class for use (and not speaking about static methods of course...which now I see the delegation in use I suppose) while aggregation objects can survive without the main 'container' object).

So I'm not sure about the aggregation aspect.

laserlight

nrg_alpha wrote:
I figured this example was a composition (if I destroy the object $objTiles, the object $obj is destroyed with it).
(...)
while aggregation objects can survive without the main 'container' object).

In this case yes, since there is no way to get a reference to the $obj data member, its lifetime is that of the corresponding floor object, and thus it is composition. However, although you may intend composition, in other cases the lifetime of the data member could exceed the lifetime of the object that supposedly owns it, if say, some other object is able to get a reference to that data member, and the lifetime of that other object exceeds the lifetime of the designated owner object.

You could read Association, Aggregation and Composition. The example for aggregation is basically an example of an array of object references, where various other objects could be referring to those objects whose references are stored in the array.

nrg_alpha wrote:
Perhaps then I'm misunderstanding things somewhat (as my understanding was delegation as tapping into the method of a separate class for use

Don't you see that you are doing that? Perhaps it would be easier to see this way, when the area method really only computes the area:

<?php
interface Shape {
    public function area();
}

class Floor {
    private $shape;

public function __construct(Shape $shape) {
    $this->shape = $shape;
}

public function computeArea() {
    return $this->shape->area();
}
}

class Rectangle implements Shape {
    private $width, $height;

public function __construct($width, $height) {
    $this->width = $width;
    $this->height = $height;
}

public function area() {
    return $this->width * $this->height;
}
}

$floor = new Floor(new Rectangle(3, 5));
echo $floor->computeArea();

nrg_alpha

Right, I'm seeing the delegation aspect of it now 🙂
Thanks for the link, laserlight... I'll read it to expand my understading on these oop principals.