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.

Gleichzeitig wollen wir aber zu jeder Zeit sicherstellen, dass wir das Model wie gewohnt vollständig abfragen und verwenden können. An dieser Stelle kommt eine Technik namens LazyLoading (lazy = engl. faul, träge) zum Einsatz.

Nun konstruiere ich einfach ein Beispiel, um den Ablauf besser erklären zu können. In unserer Anwendung brauchen wir ein Model “Person”, das Informationen wie Name, Geburtstag und diverse andere speichern kann. Den Namen und den Geburtstag brauchen wir immer (z.B. in der Listenansicht) und die restlichen Felder nur wenn wir eine Detailansicht erstellen.

Wie kommt unser Model nun an die Daten? In der Regel wird sicherlich load() auf dem Modelobjekt aufgerufen oder eine vergleichbare Methode auf der jeweiligen Collection, dann werden die Daten über ein Resourcemodel geladen und letztendlich komplett auf die einzelnen Modelobjekte kopiert.

Um unser Vorhaben umzusetzen müssen wir das etwas abändern. Die Methode load() des Models funktioniert wie gewohnt und lädt alle Daten und die Collection nur die Nötigsten. Um nun sicherzustellen, dass wir trotzdem immer alles abrufen können, muss das Model etwas intelligenter werden.

Die Entwicklung des Custom_Models hat der eine oder andere ja vielleicht mitbekommen und kennt den grundlegenden Aufbau. Relativ neu ist die Klasse Custom_Model_Persistent, durch die eine weitere Unterscheidung zwischen einfachen Datencontainern und speicherbaren Models möglich wird.

Für das automatische Nachladen muss die Modelklasse nun erweitert werden.

<?php
class Custom_Model_Persistent extends Custom_Model
{
  private $_isLoaded;

  // ...

  public function load($value = null, $field = 'id')
  {
    if (null === $value && $this->_isset($field)) {
      $value = $this->_get($field);
    }

    $this->getResource()
         ->loadModel($this, $value, $this->_mapKey($field))
         ->markLoaded();

    return $this;
  }

  public function isLoaded()
  {
    return $this->_isLoaded;
  }

  public function markLoaded()
  {
    $this->_isLoaded = true;
    return $this;
  }

  protected function _get($key, $default = null)
  {
    if (!$this->_isset($key) && !$this->isLoaded()) {
      $this->load();
    }
    return parent::_get($key, $default);
  }
}

Die entscheidenen Stellen sind hier der überschriebene zentrale Getter, der ein das “Default-Load()” auslöst, wenn der Wert nicht gesetzt ist und die Daten auch noch nicht vollständig geladen wurden und die Methode load() mit optionalen Parameter $value.

Im Beispiel verlasse ich mich darauf, dass das Standardfeld schon gesetzt ist. Eine ordentliche Fehlerbehandlung muss aber unbedingt her, wenn wir das ganze produktiv einsetzen wollen.

Die Methoden isLoaded() bzw markLoaded() sind absichtlich public, damit sie z.B. aus einer Collection aufgerufen werden können, wenn das Model komplett geladen wurde. Eine weitere Möglichkeit wäre ein Vergleich mit einer Liste die gesetzt sein sollten.

Im Moment ist das noch etwas im Entwurf und sogar ungetestet. Wenn euch nun noch was dazu einfällt, dann schreibt einen Kommentar. Wo seht ihr für euch die Vor- oder evtl. auch die Nachteile?

Ganz klar, es handelt sich um die Interfaces Iterator und IteratorAggregate. Was aber unterscheidet die beiden?

Um den Aufbau der beiden Klassen gegenüberzustellen habe ich zwei einfache Beispiel-Klassen geschrieben, mit denen wir ein Array in einer foreach-Schleife auslesen können.

Iterator

Das Interface Iterator schreibt fünf Methoden vor, die zur Verarbeitung des Objektes in einer Schleife benötigt werden: current(), next(), key(), valid() und rewind().

<?php
class TestA implements Iterator
{
  private $_items;

  public function __construct(array $items = array())
  {
    $this->_items = $items;
  }

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

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

  public function key()
  {
    return key($this->_items);
  }

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

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

Auf den ersten Blick lässt sich erkennen, dass relativ viel Code benötigt benötigt wird und dieser starr am Objekt hängt. Ok, für diesen Zweck hätte man auch den ArrayIterator nehmen können, aber dann gäbe es weniger zu gucken.

IteratorAggregate

Das zweite Iterface ist dagegen wesentlich schlanker, denn es kommt mit der einzigen Methode getIterator() aus.

<?php
class TestB implements IteratorAggregate
{
  private $_items;

  public function __construct(array $items = array())
  {
    $this->_items = $items;
  }

  public function getIterator()
  {
    return new ArrayIterator($this->_items);
  }
}

Die Methode erzeugt einen externen Iterator und lagert damit die Funktionalität in eine andere Klasse aus. Dadurch bleibt unsere Klasse übersichtlich und das Iterator-Verhalten lässt sich einfach austauschen.

Fazit

Für einfache Strukturen würde ich das IteratorAggregate-Interface vorziehen, da es sehr einfach aufgebaut ist und unseren Code schlank und übersichtlich hält. Die Funktionalität ist zudem durch verschiedene externe Klassen variabel und viele Standardfälle können mit den SPL-Klassen abgedeckt werden.

Lässt sich eine Struktur aus irgendeinem Grund nicht an einen externen Iterator übergeben, bzw. will man für diesen speziellen Fall schreiben, dann kommt das Iterator-Interface zum Einsatz.

Genaugenommen lässt sich das mit den beiden Beispielklassen schon gut testen. Einfach in der Klasse TestB

public function getIterator()
{
  return new ArrayIterator($this->_items);
}

gegen

public function getIterator()
{
  return new TestA($this->_items);
}

austauschen und etwas damit rumspielen.

In der Anwendung sind beide später identisch:

<?php
$a = new TestA(array('A','B','C','D','E'));

foreach ($a as $k => $v) {
  echo "$k = $v <br/>";
}

$b = new TestB(array('A','B','C','D','E'));

foreach ($b as $k => $v) {
  echo "$k = $v <br/>";
}

Viel Spaß damit! Eure Erkenntnisse zu dem Thema könnt ihr wie immer gerne in den Kommentaren verewigen…

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.

Ein Grund mehr mal über den PHP-Tellerrand zu spicken und einen kleine Ausflug in die Java-Welt zu machen.

PHP bietet zwar mit diversen Array-Funktionen schon einige Möglichkeiten der Sortierung an, diese sind aber doch recht starr und man stößt schnell an gewisse Grenzen, wenn man mehr als nur einfache Datentypen sortieren will, da sowohl die Sortierlogik, wie auch der Vergleich der Objekte sind nach außen in einer Funktion zusammengefasst sind.

Wie funktioniert das denn nun in der Java-Welt? In Java müssen Objekte durch das Interface “Comparable” als sortierbar gekennzeichnet werden. Die meisten Standardklassen implementieren das bereits.

Das Interface schreibt die Methode ‘compareTo” vor, die es dem Objekt erlaubt, sich mit anderen Objekten zu vergleichen. Der Rückgabewert kann 1, 0 oder -1 sein.

Dazu ein kleines Beispiel:

Leider gibt ist in der SPL noch kein derartiges Interface vorhanden, also schreibe ich es einfach mal selbst.

<?php
interface Custom_Compareable
{
  public function compareTo($object);
}

Dann brauchen wir noch ein Objekt zum Vergleichen.

<?php
class Person implements Custom_Comparable
{
  private $_id;
  private $_vorname;
  private $_nachname;
  private $_geburtsdatum;

  public function __construct($id)
  {
    $this->_id = $id;
  }

  //  Getter und Setter...

  public function compareTo($object)
  {
    if (!$object instanceof Person) {
      throw new InvalidArgumentException();
    }

    if ($this->_id < $object->_id) {
      return -1;
    } else if ($this->_id == $object->_id) {
      return 0;
    } else {
      return 1;
    }
  }
}

Damit können nun Objekte vom Typ Person standardmäßig nach ihrer Id unabhängig vom Suchalgorithmus sortiert werden.

<?php
$p1 = new Person(3);
$p2 = new Person(2);

if ($p1->compareTo($p2) < 0) {
  // swap($p1, $p2)
}

Bis jetzt haben wir zwar schon die Sortierlogik vom Vergleich der Objekte lösen können, aber trotzdem noch nicht viel gewonnen, da nur die Ids verglichen werden. Für abweichende Sortierungen lässt sich der Vergleich nun auch noch vom Personen-Objekt lösen. Dafür bietet Java das Interface “Comparator” an, bei uns wird es nun das Custom_Comparator-Interface.

<?php
interface Custom_Comparator
{
  public function compare($object1, $object2);
}

Die Methode “compare()” hat die gleichen Rückgabewerte wie “compareTo()” und kann dadurch genauso verwendet werden.

<?php
class PersonComparatorVorname implements Custom_Comparator
{
  public function compare($object1, $object2)
  {
    if (!$object1 instanceof Person || !$object2 instanceof Person) {
      throw new InvalidArgumentException();
    }

    if ($object1->getVorname() < $object2->getVorname()) {
      return -1;
    } else if ($object1->getVorname() == $object2->getVorname()) {
      return 0;
    } else {
      return 1;
    }
  }
}

Durch diese beiden Interfaces haben wir nun die Möglichkeit, unsere Objekte beliebig sortieren zu lassen. Über die Wertigkeit der Objekte entscheidet nun das Objekt selbst, bzw. ein passender Comparartor. Wie die Objekte letztendlich sortiert werden ist egal, da die Logik an einer anderen Stelle implementiert wird und nun für alle Objekte gleich funktioniert, wenn diese “Comparable” sind.

<?php
$listeMitPersonen = array(new Person(1), new Person(2));
$comparator = new PersonComparatorVorname();

// die Funktionen stehen als Pseudocode
bubblesort($listeMitPersonen);
bubblesort($listeMitPersonen, $comparator);

quicksort($listeMitPersonen);
quicksort($listeMitPersonen, $comparator);

Und auch die Logik für auf- oder absteigende Reihenfolge lässt sich komplett getrennt dank Dekorator-Pattern auslagern.

<?php
class ReverseComparator implements Custom_Comparator
{
  private $_comparator;

  public function __construct(Custom_Comparator $comparator)
  {
    $this->_comparator = $comparator;
  }

  public function compare($object1, $object2)
  {
    return $this->_comparator->compare($object1, $object2) * (-1);
  }
}

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.