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.

Zuerst erweitern wir das Interface Custom_Model_Interface um SplSubject und ein paar eigene Methoden.

<?php
interface Custom_Model_Interface
    extends ArrayAccess,
            Iterator,
            Countable,
            SplSubject
{
  public function mark();
  public function modified();
  public function cleanModified();
  public function modifiedKeys();
}

Anschliessend kümmern wir uns um die Klassen Custom_Model und bauen alles Nötige ein.

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

  public function attach(SplObserver $observer) {}
  public function detach(SplObserver $observer) {}
  public function notify() {}

  public function mark() {}
  public function modified() {}
  public function cleanModified() {}
  public function modifiedKeys() {}
  // ...
}

So weit, so gut! Die ersten drei Methoden attach(), detach() und notify() werden durch das Interface SplSubject vorgeschrieben und sind die Schnittstelle, um Observer am Objekt zu registrieren, sie zu entfernen oder zu benachrichtigen.

Mit den vier weiteren können wir den Status des Objektes setzen oder kontrollieren. Die beiden protected Eigenschaften enthalten eine Liste von Typ SplObjectStorage für die Observer und ein einfaches Array für den jeweiligen Status eines Feldes.

Bevor wir das verwenden können, müssen wir es im Konstruktor initialisieren.

public final function __construct()
{
  $this->_observers = new SplObjectStorage();
  $this->cleanModified();
  // ...
}

Der Vorteil von SplObjectStorage ist der, dass jedes Objekt nur einmal darin vorkommen kann und wir uns um die Steuerung keine Gedanken machen müssen. Das macht dann auch das Hinzufügen und Entfernen eines Observers sehr einfach.

public function attach(SplObserver $observer)
{
  $this->_observers->attach($observer);
  return $this;
}

public function detach(SplObserver $observer)
{
  $this->_observers->detach($observer);
  return $this;
}

Mir zaubert das immer ein breites Grinsen ins Gesicht, wenn eine Aufgabe mit so wenig Code gelöst werden kann und der Doc-Block teilweise länger ist als die Funktion.

Aber nun wieder zum Thema. Bevor wir uns an die wirklich einfache Benachrichtigung machen, werde ich noch schnell auf die Sache mit der Statuskontrolle eingehen. Eine Aktion, z.B. _set() setzt den “modified”-Status eines Feldes, so dass jeder Schreibzugriff auf das Modell erkennbar wird.

Dadurch haben wir später die Möglichkeit, nur zu benachrichtigen, wenn es nötig ist oder auch nur die Felder zu speichern, die sich verändert haben.

Um eine Änderung bekannt zu machen verwenden wir mark().

public function mark($key)
{
  if($this->keyExists($key)) {
    $this->_modified[$this->_mapKey($key)] = true;
  }
  return $this;
}

Die Methode erwartet den Namen eines existierenden Feldes und setzt ein Flag im Array.

Um den Status des Objektes oder eines einzelnen Feldes abfragen zu können haben wir dann modified().

public function modified($key = null)
{
  if(null !== $key) {
    return isset($this->_modified[$this->_mapKey($key)]);
  }
  return count($this->_modified) > 0;
}

Durch die Angabe des Parameters $key wird ein Feld abgefragt, ansonsten der Gesamtstatus. Nach dem selben Prinzip funktioniert dann auch cleanModified(), um den Status wieder zurück zu setzen.

public function cleanModified($key = null)
{
  if(null != $key) {
    unset($this->_modified[$this->_mapKey($key)]);
  } else {
    $this->_modified = array();
  }
  return $this;
}

Falls wir eine Liste der veränderten Felder brauchen, dann ist dafür modifiedKeys() vorgesehen.

public function modifiedKeys()
{
  $keys = array();

  foreach($this->_keys as $key) {
    if($this->modified($key)) {
      $keys[] = $key;
    }
  }

  return $keys;
}

Nachdem wir das alles durch haben, können wir uns nun notify() widmen, bevor wir unser Werk an ein paar Beispielen testen können.

public function notify()
{
  if($this->modified()) {
    foreach($this->_observers as $observer) {
      $observer->update($this);
    }
  }
  $this->cleanModified();
  return $this;
}

Die Methode macht im Prinzip nichts weiter, als bei allen in der Liste befindlichen Observer-Objekten update() aufzurufen und sich selbst als Parameter mitzugeben. Dadurch weiß die Observerklasse gleich, welches Objekt sich verändert hat.

Das folgende Beispiel zeigt einen einfachen Beobachter, der nur den Klassennamen von $subject ausgibt und eine Liste der geänderten Felder, wenn das Objekt vom Typ Custom_Model ist.

class myObserver implements SplObserver
{
  public function update(SplSubject $subject)
  {
    echo get_class($subject) . ' hat sich verändert<br/>';
    if($subject instanceof Custom_Model) {
      print_r($subject->modifiedKeys());
    }
  }
}

$model = new Person();
$model->attach(new myObserver());
$model->setId(42)
      ->setVorname('Bart');

$model->notify();

Das interessante an dem Observer-Muster ist die lose Kopplung der Objekte und die Tatsache, dass ein Observer beliebig viele Subjekte beobachten kann und umgekehrt ein Subjekt beliebig viele Observer haben kann.

So, das war es dann auch schon für diese Woche und zu diesem Thema. Wie ich einst schon sagte, ist es ein sehr ergiebiges Thema, weil sich viele Techniken in sinnvoller Verbindung anwenden lassen. Bislang haben wir trotzdem erst nur einen Datenklumpen mit etwas Dekoration.

Richtig interessant wird es dann, wenn wir die Models über Mapper-Klassen laden und speichern können, aber das wird dann evtl. das Thema einer neuen Serie…

Was kann unser Model dann, was es vorher noch nicht konnte? Durch die Verwendung des Interfaces können wir die gespeicherten Daten in einer foreach-Schleife verarbeiten. Das kann z.B. beim erzeugen von Tabellen erforderlich sein.

Wie immer beginne ich mit einer Skizze der heutigen Erweiterungen.

<?php
interface Custom_Model_Interface
  extends ArrayAccess,
          Iterator,
          Countable
{
}

Unser Interface Custom_Model_Interface erweitert zunächst das Iterator-Interface und auch Countable. Dadurch lassen sich dann die Elemente des Objektes zählen und in Verbindung mit ArrayAccess auch beliebig in einer for-Schleife verarbeiten.

In unserer Klasse müssen wir nun die entsprechenden Methoden deklarieren.

<?php
class Custom_Model implements Custom_Model_Interface
{
  // ...

  public function current() {}
  public function key() {}
  public function next() {}
  public function rewind() {}
  public function valid() {}
  public function count() {}

// ...
}

Jedem, der lange genug mit PHP arbeitet sollte nun was auffallen. Richtig! Wir halten unsere “Feldnamen” in einem Array und zu fast jeder Methode gibt es eine gleichnamige Array-Funktion.

Da wir aber an meistens an die Werte und nicht an die Namen der Felder wollen, müssen wir etwas tricksen.

Die erste Methode current() gibt das jeweilige Element an der Position des internen Zeigers zurück und entspricht damit der gleichnamigen Array-Funktion current().

public function current()
{
  return $this->_get(current($this->_keys));
}

Das Gegenstück dazu stellt quasi key() dar, da es den Feldnamen der Position liefert.

public function key()
{
  return $this->_keys[key($this->_keys)];
}

Auf den ersten Blick mag diese Schreibweise vielleicht etwas verwirren, aber nur so bekommen wir den richtigen Schlüssel. key() gibt uns den aktuellen Schlüssel von $this->_keys zurück, wir wollen den Wert der jeweiligen Position haben.

Um nun in der Schleife den internen Zeiger bewegen zu können, brauchen wir next().

public function next()
{
  next($this->_keys);
}

Wird das Objekt ein weiteres Mal mit foreach verarbeitet, so muss der interne Zeiger wieder auf die erste Position zurückgesetzt werden. Das Iterator-Interface schreibt dafür die Methode rewind() vor, die dann intern reset() verwenden kann.

public function rewind()
{
  reset($this->_keys);
}

Innerhalb der Schleife wir überprüft, ob weitere Elemente vorhanden sind. Dazu wird valid() verwendet.

public function valid()
{
  return current($this->_keys) !== false;
}

Damit haben wir alles notwendige eingebaut, damit unser Model in einer foreach-Schleife ausgelesen werden kann.

foreach($model as $key=>$value) {
  echo $key . ' = ' . $value . '<br/>';
}

Zuletzt gibt es dann auch noch die Methode count() des Countable-Interfaces, damit wir beliebig mit for-Schleifen über das Objekt iterieren können.

public function count()
{
  return count($this->_keys);    
}

und

for($i=0; $i<count($model); $i++) {
  echo $i . ' = ' . $model[$i] . '<br/>';
}

Damit wären wir auch schon wieder am Ende. Beim nächsten Mal geht es dann weiter mit dem Observer-Pattern.