Damit ist dann zumindest der eine Teil, die Datenstruktur, für sich gekapselt. Was ist aber mit dem Teil, den wir wahrscheinlich häufiger verwenden werden? Wir nutzen Iteratoren in Schleifen und machen irgendwas mit den Elementen.

<?php
foreach($list as $key => $item) {
  $item->doSomething();
}

// oder
$values = array();
foreach($list as $key => $item) {
  $values[] = $item->getSomething();
}

In verschiedenen anderen Sprachen, Java, JavaScript etc., sieht man häufig, dass dort auch die Scheifen gekapselt sind. Warum probieren wir das nicht auch mal in PHP?

Ich werde das Beipiel bewusst einfach halten und wie gewohnt auf einige Fehlerbehandlungen verzichten, um den Code übersichtlich zu halten.

Als erstes erstellen wir eine Klasse “WalkableIterator” und lassen diese von ArrayIterator erben. Die beiden Methoden “each” und “walk” bilden später unsere beiden Beispiele ab.

<?php
class WalkableIterator extends ArrayIterator {
  public function each($method) {}
  public function walk($callback) {}
}

Mit each() können wir eine bestimmte Methode auf jedem Element in unserem Iterator aufrufen. Dafür müssten hier natürlich diverse Fehlerbehandlungen rein was passieren soll, wenn das Element kein Objekt ist oder die Methode nicht existiert oder diese gar eine Exception wirft.

<?php
class WalkableIterator extends ArrayIterator {
  public function each($method) {
    $args = func_get_args();
    $method = array_shift($args);
    foreach($this as $item) {
      call_user_func_array( array($item, $method), $args );
    }
  }
  // ...
}

Das ganze ist denkbar einfach: Die Methode nimmt als ersten Pflichtparameter den Methodennamen entgegen, die auf allen Elementen aufgerufen werden soll und der Rest bleibt flexibel und wird einfach nur durchgereicht.

Die Implementierung von walk() wird sogar noch einfacher, da hier keine Parameter weitergegeben werden müssen. Im produktiven Einsatz müssten auch hier noch die üblichen Fehlerbehandlungen rein.

<?php
class WalkableIterator extends ArrayIterator {
  // ...
  public function walk($callback) {
    foreach($this as $item) {
      call_user_func( $callback, $item );
    }
  }
}

Soweit, so einfach… Was können wir jetzt damit machen? Bauen wir ein kleines Beispiel.

<?php
// Testklasse
class Person {
  private $name;
  public function __construct($name = 'unnamed') {
    $this->setName($name);
  }
  public function getName() {
    return $this->name;
  }
  public function setName($name) {
    $this->name = $name;
  }
}

// Testarray mit Objekten befüllen
$a = array();
for($i=1; $i <= 10; $i++) {
  $a[] = new Person('Person ' . $i);
}

// Iterator erstellen und Namen ausgeben
$it = new WalkableIterator($a);

foreach($it as $item) {
  echo $item->getName() . '<br/>';
}

// Person 1
// ...
// Person 10

Wollten wir nun allen Personenobjekten einen Namen geben, so könnten wir dafür each() verwenden.

<?php
$it->each('setName', 'PHP-Nerd');

// PHP-Nerd
// ...
// PHP-Nerd

Wollen wir unsere Personen dann vielleicht doch wieder individueller benennen, so könnten wird das mit walk() und einem Callback machen.

$callback = function(Person $person) {
  static $count = 1;
  $person->setName( $person->getName() . ' ' . $count++ );
};

$it->walk($callback);

// PHP-Nerd 1
// ...
// PHP-Nerd 10

“Was bringt uns das und warum so kompliziert?”, ist in dem Zusammenhang eine oft gehörte Frage.

Zunächst ist die Implementierung, wie das Beispiel sicher beweist, nicht kompliziert.

Die Vorteile sind kürzere Aufrufe im Code, weil wir keine Schleifen mehr schreiben müssen und durch die Kapselung verbessert sich auch die Wart- und Testbarkeit. Der Code existiert nur an einer Stelle und funktioniert überall nach dem selben Muster.

Das Prinzip ist einfach: in der (abstrakten) Basisklasse wird eine leere Methode definiert, die durch eine konkrete Klasse überschrieben werden kann.

Der Vorteil ist recht offensichtlich. Die Methode kann ohne vorherige Prüfung verwendet werden und das spart an vielen Stellen unnötigen Code. Aus meinem ästhetischem Empfinden der richtige Weg.

Aber auch den anderen Weg habe ich auch schon desöfteren gesehen und mein Bauchgefühl hat ja auch nicht immer recht. Vielleicht ist der schöne Weg ja auch der langsamere?

Gefühl ist gut, Zahlen sind besser! Also habe ich schnell drei Testklassen geschrieben und probiere die verschiedenen Möglichkeiten durch.

Variante 1: Wir verlassen uns darauf, dass die Methode aufgerufen werden kann.

<?php
class Test1 {
    public function machWas() {
        $this->machWasAnderes();
    }

    public function machWasAnderes() {
    }
}

Variante 2: Wir prüfen, ob die Methode existiert und finden nichts.

<?php
class Test2 {
    public function machWas() {
        if (method_exists($this, 'machWasAnderes')) {
            $this->machWasAnderes();
        }
    }
}

Variante 3: Wir prüfen, ob die Methode existiert und rufen sie auf.

<?php
class Test3 {
    public function machWas() {
        if (method_exists($this, 'machWasAnderes')) {
            $this->machWasAnderes();
        }
    }

    public function machWasAnderes() {
    }
}

Zum Vergleich habe ich das folgende Script verwendet.

<?php
foreach (array('Test1', 'Test2', 'Test3') as $class) {
    $object = new $class();
    $start = microtime(true);

    for($i=0; $i<100000; $i++) {
        $object->machWas();
    }
    echo $class . ' = ' . round(microtime(true) - $start, 5) . '<br/>';
}

Ausgabe:

Test1 = 0.44767
Test2 = 0.48588
Test3 = 0.70881

In mehreren Durchläufen waren “Test1″ und “Test2″ immer fast gleich auf, nur “Test3″ brauchte etwas länger, weil in der Klasse die Prüfung und die Ausführung der Methode stattfindet.

Fazit: Der Einsatz von Schablonenmethoden lohnt sich doppelt, da der Code übersichtlich bleibt und auch die Geschwindigkeit etwas besser ist.

Der herkömmliche Weg eine Instanz einer Klasse zu erzeugen ist die Verwendung des new-Operators.

<?php
$meinObject = new MeineKlasse();
$meineKlasse->machWas();

Leider funktioniert Methodenverkettung in PHP nicht wie in Java direkt nach “new” und wir müssen uns mit einer statischen Methode behelfen. Das Prinzip ähnelt dem Singleton-Muster, jedoch wollen wir in diesem Fall bei jedem Aufruf eine neue Instanz bekommen. Wer schonmal mit (Borland-)Delphi gearbeitet hat, der kennt das sicher schon.

<?php
class MeineKlasse
{
  public static function create()
  {
    return new self();
  }
}

Der Vorteil ist nun ganz klar der, dass sich Instanzen in einer Zeile benutzen lassen.

<?php
MeineKlasse::create()->machWas();

Leider fallen mir aber auch spontan zwei Nachteile ein: Bis PHP 5.3 ist die Methode nicht vererbbar, das bedeutet, dass wir die Methode mit jeder Ableitung erneut überschreiben müssten. Ab Version 5.3 kann statt “self” dann “static” instanziiert werden. Genaueres findet sich auch in den Links in meinem Singleton-Artikel.

Der zweite Nachteil ist genau der, warum man auch “new” nicht verwenden sollte. Beides schafft an vielen Stellen im Code Abhängigkeitet zu einer bestimmten Klasse. Wenn nun irgendwann eine abgeleitete Klasse benötigt wird müssen viele Änderungen gemacht werden.

Im Zweifelsfall sollte auf eine klassische, externe Factory zurückgegriffen werden, um derartigen Problemen im Voraus aus dem Weg zu gehen.

Wirklich störend war aus meiner Sicht bislang nur, dass sich das Singleton nicht vererben ließ. Dank Late Static Binding seit PHP Version 5.3 ist nun auch das möglich.

Dazu habe ich vor ein paar Tagen einen guten Artikel von Julian gefunden und auch noch einen englischsprachigen im Blog von Brandon.

Bevor ich aber nun der Miss World 2010 die Scherpe streitig mache, fange ich lieber mal an…

Stellen wir uns mal vor, wir haben ein Meta-Model, welches verschiedene allgemeine Daten zu einem anderen Objekt speichern kann.

<?php
class MetaModel extends Custom_Model
{
  protected $_ownerId;
  protected $_creatorId;
  protected $_modifierId;
  protected $_createDate;
  protected $_modifyDate;

  // Weitere Felder und Getter/Setter
}

Die ersten drei Felder sind jeweils UserIds und die anderen zwei Datumswerte, die wir über gewöhnliche Getter und Setter verändern können. Damit können wir schonmal mit den Daten arbeiten, jedoch leider nicht objektorientiert navigieren.

Mit Navigation meine ich einen einfachen und für Menschen leicht lesbaren Zugriff auf die Objekte. Im Prinzip nur eine einfache Methodenverkettung.

<?php
$ownerName = $object->getMeta()->getOwner()->getName();

Anders herum will ich vielleicht auch die Möglichkeit haben ein Datum als String oder als Objekt zu setzen und will ganz sicher nicht in jedem einzelnen Setter die Unterscheidung implementieren.

Die Lösung ist denkbar einfach. Wir lagern den benötigten Code einfach aus! Wer sich etwas mit Design Patterns beschäftigt, der erkennt sicher das Strategy Pattern wieder.

Als erstes definieren wir eine einfache Schnittstelle und bauen uns dannach einen “Accessor”.

<?php
interface Custom_Model_Access_Interface
{
  public function get($value);
  public function set($value);
}

<?php
class Custom_Model_Access_User implements Custom_Model_Access_Interface
{
  /**
   * @param int $value
   * @return UserModel
  public function get($value)
  {
    // UserModel laden ($value==ID)
  }

  /**
   * @param mixed int|UserModel
   * @return int (UserId)
   */
  public function set($value)
  {
    // $value->getId() zurückgeben, wenn $value ein UserModel ist, sonst $value
  }
}

Damit haben wir, wenn auch stark vereinfacht, die Logik ausgelagert und können sie nun in der Modelklasse nutzen. Für viele dieser Access-Objekte reicht eine Instanz aus, die wir am besten über eine einfache Factory erzeugen.

In unserem Model sieht das dann wie folgt aus.

<?php
class MetaModel extends Custom_Model
{
  // ...
  private $_accessUser;

  public function init()
  {
    $this->_accessUser = Custom_Model_Access_Factory::singleton('User');
  }

  public function getOwner()
  {
    return $this->_accessUser->get( $this->getOwnerId() );
  }

  public function setOwner($owner)
  {
    return $this->setOwnerId( $this->_accessUser->set($owner) );
  }
}

Nach diesem Muster würden nun auch die Methoden für creator und modifier geschrieben werden. An dieser Stelle wäre auch ein einfacher Cache möglich, damit das Objekt nicht bei jedem Aufruf erneut instanziiert werden muss.

Das Access-Objekt für das Datum könnte unter Umständen etwas umfangreicher werden.

Der Getter sollte uns ein Datums-Objekt zurückgeben anhand des in der Datenbank (oder wo auch immer) gespeicherten Werten, egal in welchem Format dieser vorliegt.

Der Setter auf der andern Seite könnte z.B. sämtlichen gängigen Datums-Objekte und Stringformate kennen und diese in das übliche Y-m-d H:i:s-Format übersetzen.

Zusammenfassend lässt sich festhalten, dass sich diese Technik für alle möglichen Bereiche geeignet ist, wenn man Objekte zu den Ids haben möchte oder auch Formate umwandeln will oder muss (Datum, IP-Adressen etc.).

Wenn euch noch etwas sinnvolles zur Verwendung einfällt oder einfach noch Fragen oder Kritik offen sind, dann freue ich mich über Kommentare.

Alle, die bislang nur wenig oder keine Erfahrung mit MVC-Anwendungen gesammelt haben, werden sich vielleicht nun fragen, wofür dieses Objekt gut ist. Das Response-Objekt kontrolliert die komplette Ausgabe der Anwendung an den Client (z.B. einen Browser).

Während der kompletten Laufzeit können mit dem Objekt Ausgaben gesammelt und auch nachträglich verändert werden und auch die Reihenfolge spielt keine Rolle. So kann nun zuerst die Ausgabe gemacht werden und dann die Header gesetzt werden.

So müsste es klassisch mit PHP geschrieben werden:

<?php header('Content-type: text/xml'); echo $xml;

Wenn wir nun die Reihenfolge vertauschen würden, hätte das eine Warning zur Folge.

<?php echo $xml; header('Content-type: text/xml');

Warning: Cannot modify header information - headers already sent by (output started at ####) in #### on line 3

Wenn wir uns in einer MVC-Umgebung befinden, stellt diese Reihenfolge kein Problem dar, denn das Objekt verwaltet die Ausgabe und schickt alles zur rechten Zeit raus.

So könnte es dann z.B. in einer Action des Kontrollers aussehen:

<?php public function indexAction() { // ... $this->getResponse()->appendBody($xml); $this->getResponse()->setHeader('Content-type', 'text/xml'); } 

Neben den relativ harmlosen direkten Ausgaben mit echo oder print habe ich in den vergangenen Jahren auch Ausgaben mit die() gefunden. Die offensichtliche Arbeit verrichtet die Anwendung zwar in den Actions der Kontroller, aber es passiert unter Umständen auch vor- und nachher eine Menge. Letzteres würde dann unterbunden werden und evtl. wichtige Aufgaben nicht mehr abgearbeitet werden.

Ein Beispiel sah etwa so aus:

<?php
public function jsonAction()
{
  // ...
  header('Content-type: text/json');
  die($json);
  // ...
}

Die Anwendung verliert so die Kontrolle über die Ausgabe und wird an der falschen Stelle beendet. Der richtige Weg führt auch hier zum Response-Objekt.

<?php
public function jsonAction()
{
  // ...
  $this->getResponse()->setHeader('COntent-type', 'text/json');
  $this->getResponse()->appendBody($json);
  return;  // <== falls die Bearbeitung hier enden soll
  // ...
}

So, nun gibt es in Zukunft keine Ausreden mehr, wenn irgendwo ein echo im Kontroller steht. Ich würde mich natürlich wie immer freuen eure Erfahrungen in den Kommentaren zu lesen.

Nebenbei bemerkt ist das mein 50. Artikel, also schon fast ein kleiner Grund zum Feiern.

Und schon wieder die Frage, was kann unsere Klasse dann mehr? Oder warum machen wir das?

Oftmals haben wir Objekte, die eine gewisse Menge identischer Methoden benötigen, jedoch nicht aus einer Vererbungslinie stammen.

Durch die Plugins können wir dann quasi Funktionen an unsere Objekte dran kleben und nutzen. Diesen Code müssen wir nur einmal schreiben, haben auch nur eine Stelle im Code zu pflegen und können dadurch sicherstellen, dass alles gleich funktioniert.

So erweitern wir nun also zuerst wie gewohnt unser Custom_Model um ein paar neue Methoden und Eigenschaften.

<?php
class Custom_Model implements Custom_Model_Interface
{
  // ...
  protected $_plugins;

  public function registerPlugin() {}
  public function unregisterPlugin() {}
  // ...
}

Und das Interface für die Plugins.

<?php
interface Custom_Model_Plugin_Interface {}

Beim Speichern der Plugins kommt wieder die Klasse SplObjectStorage zum Einsatz, welche wir ja schon bei der Implementierung des Obeservers verwendet haben. Demnach ist es auch nicht überraschend, dass die Registrierung an die Abmeldung der Plugins sehr einfach wird.

public function registerPlugin(Custom_Model_Plugin_Interface $plugin)
{
  $this->_plugins->attach($plugin);
  return $this;
}

public function unregisterPlugin(Custom_Model_Plugin_Interface $plugin)
{
  $this->_plugins->detach($plugin);
  return $this;
}

Die Models müssen das Interface Custom_Model_Plugin_Interface implementieren. Dieses Interface ist lediglich ein Flag- oder Marker-Interface, d.h. es schreibt keine Methoden vor.

Jetzt noch eine kleine Änderung an der Methode __call() und wir können schon mit dem Beispiel experimentieren.

public function __call($method, $args)
{
  // Magie für die Getter & Setter

  foreach($this->_plugins as $plugin) {
    if(method_exists($plugin, $method)) {
      array_unshift($args, $this);
      return call_user_func_array(array($plugin, $method), $args);
    }
  }

  // Fehlerbehandlung
}

Durch __call() können wir unsere Plugin-Methoden so nutzen, als gehörten sie direkt zum Objekt. Die Art wie die Plugins verwendet werden  hat Vor-, aber auch Nachteile.

Die Liste der Plugins wird der Reihe nach durchlaufen und die erstbeste passende Methode wird aufgerufen. Auch die Getter oder Setter könnten wir nicht mehr überschreiben. Wenn das alles jedoch gewollt ist, dann lässt sich das aber auch mit wenigen Handgriffen erweitern.

Nun aber mal was praktisches zum Anschauen: Angenommen wir haben eine Model-Klasse mit Abhängigkeit zu anderen Objekten.

<?php
class Book extends Custom_Model
{
  protected $_id;
  protected $_title;
  protected $_ownerId;
}

Nun wollen wir nicht nur die ID des Besitzers erfahren, sondern auch das Objekt das bekommen können. Dafür spendieren wir ein Plugin.

<?php
class GetOwnerPlugin implements Custom_Model_Plugin_Interface
{
  public function getOwner($sender)
  {
    $id = $sender->getOwnerId();

    // lade User-Objekt $owner anhand der $id

    return $owner;
  }
}

Auf die Fehlerbehandlung habe ich an der Stelle mal verzichtet, sollte jedoch unbedingt stattfinden.

<?php
$book = new Book();
$book->registerPlugin(new GetOwnerPlugin());
$book->setOwnerId(42);
$owner = $book->getOwner();

Spätestens hier fällt sicher nicht nur mir auf, dass das Konzept noch Lücken hat. Theoretisch kann es sein, dass zu verschiedenen IDs ein User-Objekt nachgeladen werden soll (getAuthor(), getModifier(), getLastVisitor()…) und dann bräuchten wir sämtliche Methoden in unserem Plugin oder verschiedene Plugins.

Dann hätten wir aber auch wieder mehrfachen Code und nichts gewonnen. Daher werde ich die Pluginschnittstelle noch etwas aufbohren und das Ergebnis dann in einem meiner nächsten Artikel vorstellen.