[TYPO3-ect] News about XCLASSES?

[Oliver Hader]

Ernesto Baschny [cron IT] wrote:
> You create a new class that implements the complete interface of the
> original class (i.e. it provides all methods from the "inherited"
> class). The constructor gets an instance of the original class and you
> start with calling all original methods on that instance that you get
> passed. Then you can simply add or change or enhance certain methods to
> do what you want it to do. As the constructor gets an instance of the
> class with the same interface, it is easy to "chain" together many classes.

That's true. Real decorators must have the complete interface as it is
present the decorated class. But in PHP5 we could use something new, the
__call($method, $args) for calling the method from the decorated class.

I've created a small example on the decorator usage. Decorators have
appropriate class names, the decorated classes a called "Components".
In that example it's possible to build up a multi-functional-object that
has all functionallity of the component class and all involved
decorators. I removed some stuff, just to get the idea, the complete
code is shown at http://devel.t3ip.de/decorator.php.txt.

So here we go:


$digitComponent = new DigitComponent(16, 2);
// give it a try, and create a "hyper" functional class
$hyperObject =
new SummateDecorator(
	new DivideDecorator(
		new MultiplyDecorator(
			$digitComponent
		)
	)
);
$hyperObject->divide();
$hyperObject->multiply();
$hyperObject->summate();
$hyperObject->show();


/**
 * Here come the components we are working on.
 * This could be any type of content.
 */
abstract class Component {
	public $content = '';

	public function show() {}
	public function addBR() {}
}

class DigitComponent extends Component {
	public $numberA;
	public $numberB;
	public function __construct($numberA, $numberB) {}
}

/**
 * Here come our decorators playing with the components in some way.
 */
abstract class Decorator extends Component {
	protected $component;

	public function __construct(Component &$component) {
		$this->component =& $component;
	}
	
	public function show() {
		// call the show method of the component
		$this->component->show();
	}

	public function __call($method, $args) {
		// fetch calls to currenty unsupported methods an try
		// on the decorated component
		call_user_method($method, $this->component, $args);
	}
	
	public function getComponent() {
		$component =& $this->component;

		// iterate out of decorators up to the component
		while ($component instanceof Decorator)
			$component =& $component->component;

		// return the component so we can work on it
		return $component;
	}
}

class MultiplyDecorator extends Decorator {
	public function multiply() {}
}

class DivideDecorator extends Decorator {
	public function divide() {}
}

class SummateDecorator extends Decorator {
	public function summate() {}
}


So you can see, that the methods divide, summate, multiply are sticked
together with several decorator classes. Probably someone finds some
errors in my "two decorator-cents", but it should just show, how it
could work.


> When TYPO3 then needs to create a cObj and our extension has
> "registered" somehow that we provide an enhancement to it, the
> makeInstance method just has to chain that together:
> 
> function &makeInstance($className) {
>   $obj =& new $className;
>   $decorators =
> $GLOBALS['TYPO3_CONF_VARS']['SYS']['OBJ_DECORATORS'][$className];
>   foreach ($decorators as $dec) {
>     $obj =& new $dec($obj);
>   }
>   return $obj;
> }
> 
> This is untested, I just made it out! :)
> 

I also didn't check this, but I'm sure that this will work! ;)

On using decorators the system would get very complex very fast. So if
there is no documentation or "plan" how to use decorators in TYPO3, give
it some months and nobody knows again which decorator solves which problem.
An advantage is that you could build your own objects, depending on your
special demands. The disadvantage could be, that laziness finds it's way
it that topic and everything is fired up using all available decorators
and kills performace step by step.

But I like the idea of using design patterns in general - as you all can
imagine, "decorator" is not the only one out there... ;)


Regards,
Olly