Welches Entwurfsmuster steckt in Traits

[Rolf B]

Hallo pl,

warum probierst Du es nicht aus

Im einfachen Fall sieht das so aus:

<?php
trait RSS {
    function _rss() {
        echo "Here is your RSS feed for the $this->pageName forum\n";
    }
}
class Forum {
    use RSS;
    private $pageName;
    function __construct($name) {
        $this->pageName = $name;
    }
    function control() {
        $this->_rss();
    }
}

$f = new Forum("Demo");
$f->control();

Aber ich finde es unschön, dass der Trait an den Daten des Objekts herummatscht. Besser finde ich:

<?php
trait RSS {
    function _rss() {
        echo "Here is your RSS feed for the {$this->getName()} forum\n";
    }
    abstract function getName();
}
class Forum {
    use RSS;
    private $pageName;
    function __construct($name) {
        $this->pageName = $name;
    }
    function control() {
        $this->_rss();
    }
    function getName() {
        return $this->pageName;
    }
}

$f = new Forum("Demo");
$f->control();

Hier wird die nutzende Klasse gezwungen, dem Trait die erforderliche Schnittstelle bereitzustellen.

Unter PHP 5.3 dagegen muss man den Trait entweder als Objekt bereitstellen oder statische Methoden verwenden. Ich würde es vielleicht über eine Servicefactory lösen.

<?php
class RSS {
    function render($forum) {
        echo "Here is your RSS feed for the {$forum->getName()} forum\n";
    }
}
class Forum {
    private $pageName;
    function __construct($name) {
        $this->pageName = $name;
    }
    function control($serviceFactory) {
        $rss = $serviceFactory->getService("RSS");    // so
        $rss = $serviceFactory->getRssService();      // oder so
        $rss->render($this);
    }
    function getName() {
        return $this->pageName;
    }
}

$f = new Forum("Demo");
$f->control($serviceFactory);

Vermutlich würde ich diesen Ansatz auch dann wählen, wenn ich PHP 5.4 oder höher hätte. Grund: Der Code für den RSS Feed wird nur gebraucht wenn der RSS Feed explizt angefordert wird. Ansonsten braucht sich PHP damit nicht zu befassen. Und das Darstellen der Topics in HTML würde ich vermutlich über einen weiteren Service implementieren.

Wobei - im konkreten Fall könnte es genügen, zwei unterschiedliche Templates anzuwenden...

Rolf