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.

Was ist aber eigentlich passiert? Für eine bestimmte Aufgabe musste ich Daten in der SimpleDB (Amazon Webservices) zwischengespeichern und dann an anderer Stelle weiter verarbeitet. Nun passiert es hin und wieder, dass meine Weiterleitung schneller als die Datenbank war und ich die Daten (noch) nicht lesen konnte.

Was macht man in diesem Fall? Abwarten, Tee trinken und nochmal probieren. In dem Fall kamen ein paar Zeilen Code dazu und alles lief wie gewünscht. Wirklich schick ist das jedoch so noch nicht.

Erstmal eine einfach Beipielklasse im PHP-Pseudocode zum besseren Verständnis:

<?php
class SomeWebResource
{
  public function load($key)
  {
    // do something
    return $data;
  }

  public function save($key, $data)
  {
    // do something
    return $flag;
  }

  public function delete($key)
  {
    // do something
    return $flag;
  }
}

In diesem Beispiel hat unsere Klasse drei Methoden, in denen die selben oder zumindest ähnliche Probleme auftreten können. Die Daten haben das falsche Format, der Webservice ist nicht erreichbar oder was auch immer.

Für diesen Fall bauen wir dann nun die Wiederholung ein.

<?php
class SomeWebResource
{
  public function load($key)
  {
    $count = 0;
    do {
      try {
        // do something
        return $data;
      } catch (Exception $e) {
        sleep(1);
      }
    } while (3 > $count++);
  }

  public function save($key, $data)
  {
    $count = 0;
    do {
      try {
        // do something
        return $flag;
      } catch (Exception $e) {
        sleep(1);
      }
    } while (3 > $count++);
  }

  public function delete($key)
  {
    $count = 0;
    do {
      try {
        // do something
        return $flag;
      } catch (Exception $e) {
        sleep(1);
      }
    } while (3 > $count++);
  }
}

Spontan sollten nun jedem mindestens drei Dinge auffallen. Der Code ist gleich um etliche Zeilen länger und wiederholt sich, man könnte fast ein Muster (Pattern) erkennen. Der Code ist nicht wirklich flexibel, wenn es darum geht die Wartezeit oder die Anzahl der Versuche zu konfigurieren. Der Code ist immer da und lässt sich so nicht mehr ohne die Wiederholung ausführen und es ist nicht die Aufgabe dieser Klasse die Wiederholungen zu kontrollieren.

In dem Fall schreit es doch gerade danach, diesen Code recyclebar auszulagern, findet ihr nicht?

Dafür brauchen wir nur eine einfache Proxy-Klasse. Ok, bevor jetzt jemand protestiert, dass sei doch garnicht das Proxy-Pattern, stimmt! Wir leiten die Proxy-Klasse nicht von der Klasse “SomeWebResource” ab und haben dadurch eine andere Schnittstelle. In diesem Fall ist das aber egal, denn wir leiten ja auch nur den Methodenaufruf weiter.

Nun aber erstmal die RetryProxy-Klasse:

<?php
class E7_Tools_RetryProxy
{
  // some other methods

  public function call($callback)
  {
    $exception = null;
    $count = 0;
    $args = func_get_args();
    array_shift($args);

    do {
      try {
        return call_user_func_array($callback, $args);
      } catch (Exception $e) {
        $exception = $e;
        sleep($this->getDelay());
      }
    } while ($this->getRepititions() > $count++);

    if ($exception instanceof Exception) {
      throw $exception;
    }
  }
}

Auch hier lässt sich natürlich das selbe Muster erkennen, aber wir haben es von jeder weitern Logik entkoppelt und die gewünschten Werte lassen sich nun einfach über die Setter einstellen.

Die Verwendung ist später ebenfalls einfach.

<?php
$proxy = new E7_Tools_RetryProxy();
$swr   = new SomeWebResource();
$data  = $proxy->call(array($swr, 'load'), 42);

Wer damit etwas experimentieren will, findet die komplette Klasse hier. Wie immer freue ich mich natürlich über möglichst zahlreiche Kommentare.

Als ich mich vor ein paar Jahren auf meine Java-Zertifizierung vorbereitet habe, ist mir ein Satz immer wieder begegnet: “Programm to an interface, not to an implementation!”. Klingt einfach, ist es auch.

Im Prinzip sagt das nur aus, dass man sich beim Entwickeln nur darauf verlassen sollte, was die jeweilig implementierten Interfaces an Funktionalität anbieten. Wie das ganze dann im Hintergrund implementiert ist, interessiert dann nicht mehr.

Ein kleines Beispiel aus der Praxis: In einem Shop (in dem Fall Magento) werden Bestellungen (Orders) gespeichert. Nun soll ein ERP-System angebunden werden. Für beide Systeme gibt es entsprechende Models, mit denen die Daten verarbeitet werden können.

Soweit, so gut. Jetzt kommt der unbequeme Teil der Aufgabe. Das Magento-Order-Model erbt einfach nur von verschiedenen anderen Klassen, aber es existiert kein Interface, das dem Entwickler bestimmte Methoden garantiert. An vielen Stellen werden zudem die Parameter mit Type-Hinting überprüft, ob sie eine Magento-Order enthalten.

Das Model für die Anbindung an das ERP-System hat unter Umständen andere Elternklassen und somit auch erstmal keine Gemeinsamkeiten. Das bedeutet, dass wir theoretisch die Objekte gleich behandeln könnten, aber wir sie für das Type-Hinting doch wieder in Wrapper verpacken oder auf Magento-Order-Objekte mappen müssen.

Diese Arbeit könnte man sich komplett sparen, wenn man sich von Anfang an auf ein Interface verlassen hätte. Leider existiert dieses meines Wissens nicht und es für eigene Projekte zu nutzen würde Änderungen in den Magento-Core-Dateien fordern.

<?php
interface Mage_Sales_Model_Order_Interface
{
  /**
   * Retrieve customer model
   *
   * @return Mage_Customer_Model_Customer_Interface
   */
  public function getCustomer();

  // ...
}

Damit könnte man sich auf verschiedene Methoden verlassen die der Typ Mage_Sales_Model_Order_Interface (!) zusagt.

<?php
class Mage_Sales_Model_Order
  extends Mage_Sales_Model_Abstract
  implements Mage_Sales_Model_Order_Interface
{
  // ...
}

Die Klasse Mage_Sales_Model_Order könnte sich an diesen “Vertrag” halten,

<?php
class Erp_Sales_Model_Order
  extends Erp_Was_Auch_Immer_Model_Abstract
  implements Mage_Sales_Model_Order_Interface
{
  // ...
}

sowie auch jede andere Klasse.

<?php
// ...
public function getEmailFromOrder(Mage_Sales_Model_Order_Interface $order)
{
  return $order->getCustomer()->getEmail();
}
// ...

So können wir jede beliebige Klasse mit bestehenden Code weiterhin verarbeiten, ohne dass uns das Type-Hinting dabei im Weg steht. Was die Methode getCustomer() nun intern macht, ist uns egal, solange ein Objekt vom Typ Mage_Customer_Model_Customer_Interface zurückgegeben wird.

Es ist vielleicht auf den ersten Blick etwas umständlicher, für jeden Typ ein Interface zu schreiben, aber das spart man danach wieder locker ein und bleibt dazu auch in der weiteren Entwicklung seiner Anwendung flexibel.

Ganz im Gegenteil, sogar! Während meiner Arbeit mit Amazon S3 kam mir der Gedanke, dass es doch sehr bequem wäre, wenn es einen Stream Wrapper gäbe und man die PHP-eigenen File-Funktionen zum Lesen und Schreiben verwenden könnte.

Nach kurzem Suchen habe ich, wen wird es überraschen, eine noch einfachere Lösung gefunden. Zuerst aber mein Versuch mit Zend_Cloud Dateien nach Amazon S3 zu kopieren.

Zend_Cloud

Einfach die Storage-Factory mit den nötigen Zugangsdaten füttern und schon kann es losgehen.

<?php
$adapter      = 'Zend_Cloud_StorageService_Adapter_S3';
$amazonKey    = '<amazon-key>';
$amazonSecret = '<amazon-secret>';
$bucketName   = 'mein-bucket';

$storage = Zend_Cloud_StorageService_Factory::getAdapter(array(
  Zend_Cloud_StorageService_Factory::STORAGE_ADAPTER_KEY => $adapter,
  Zend_Cloud_StorageService_Adapter_S3::AWS_ACCESS_KEY   => $amazonKey,
  Zend_Cloud_StorageService_Adapter_S3::AWS_SECRET_KEY   => $amazonSecret,
  Zend_Cloud_StorageService_Adapter_S3::BUCKET_NAME      => $bucketName,
));

Die Factory liefert uns ein gebrauchsfertiges Objekt zurück, mit dem wir nun Dateien erzeugen können.

<?php
$filename = 'example.txt';
$data = file_get_contents($filename);
$storage->storeItem($filename, $data);

Ebenso einfach wie das Erstellen ist auch das Lesen…

<?php
echo $storage->fetchItem($filename));

…oder Löschen einer Datei.

<?php
$storage->deleteItem($filename);

Zend_Service

Nun hatte ich ja versprochen, dass es noch einfacher geht. Die Komponente Zend_Service bietet ebenfalls eine Schnittstelle für Amazon S3 an und auch gleich eine Methode, diese als Stream Wrapper zu registrieren.

Zuerst muss natürlich das Objekt mit den Zugangsdaten erzeugt werden.

<?php
$amazonKey    = '<amazon-key>';
$amazonSecret = '<amazon-secret>';

$s3 = new Zend_Service_Amazon_S3($amazonKey, $amazonSecret);
$s3->registerStreamWrapper('s3');

Ab jetzt ist der Stream Wrapper mit dem Schema ‘s3://’ im System bekannt und mit den gewohnten File-Funktionen verwendet werden. Dadurch bleibt der Code schlank und man muss sich nicht für jede Speicherart eine andere Schnittstelle merken.

Nicht zuletzt können wir unsere Dateien nun organisieren wie und wo wir wollen ohne dabei wieder den Code umschreiben zu müssen.

<?php
file_put_contents("s3://<bucket-name>/halloWelt", "Hallo Welt"); // einfach schreiben
echo file_get_contents("s3://<bucket-name>/halloWelt"); // und wieder lesen

Nebenbei bemerkt ist es auch recht einfach, sich einen eigenen Stream Wrapper für spezielle Anwendungfälle selber zu schreiben, aber dazu vielleicht mehr in einem weiteren Artikel.

Aber nach mir geht es nicht, das Leben ist kein Ponyhof und ich habe mich so entschieden mein Geld mit PHP- und nicht mit Java-Programmierung zu verdienen. Genug gejammert, worum geht es?

In den letzten Tagen, Urlaub sei Dank, hatte ich etwas mehr Zeit mich durch die Blogwelt zu klicken und habe dabei einen älteren Artikel von Benjamin entdeckt, in dem er seine PHP-Stringklasse vorstellt. Etwas schmunzeln musste ich bei der Lizenz für die wenigen Zeilen Code, aber Ordnung muss sein.

Die Idee gefällt mir sehr gut keine primitiven Datentypen, sondern echte Objekte zu verwenden.

Inspiriert von der Idee, habe ich ein paar Minuten gebastelt und habe nun meine Custom_String-Klasse. Sie ist einfach umgesetzt, handlich und hat alles was ich brauche.

An der Stelle fiel mir dann auch gleich wieder ein, warum ich das bisher nicht umgesetzt habe.

Wer sich etwas mit Java auskennt, der weiß, dass sämtliche Objekte in gewisser Weise nach bestimmten Mustern funktionieren. Will ich meine Objekte sortieren können, dann implementiere ich einfach das Interface Comparable und gut ist.

An dem Beispiel mit den Strings sollte das Problem klar werden. Benjamin hat eine Klasse für Strings geschrieben, wie er sie gerne hätte, ich habe das getan und viele andere vielleicht auch.

Jede für sich mag gut sein, aber auch etwas anders funktionieren und eine andere Schnittstelle bieten.

In großen Systemen kommen nun die Arbeiten vieler Entwickler zusammen, teilweise sogar aus verschiedenen Teams oder auch Firmen.

Um nun einheitlich mit allen Objekten arbeiten zu können, brauchen wir zwangsläufig Adapter-Klassen und haben damit weitere potentielle Schwachstellen im System. Wir müssten jedes Objekt an den Schnittstellen richtig verpacken und bauschen dadurch den Code auf und wir haben die Adapter-Klassen, die wir ebenfalls mit jeder Änderung der Originalklassen anpassen müssen.

Ich denke, solange PHP nicht im Kern ähnlich wie Java die entsprechenden Schnittstellen vorgibt, macht man sich das Entwicklerleben damit nicht wirklich leichter. Wie denkt ihr darüber?

Wir kennen es sicher alle: Wir haben irgendein Objekt und wollen dessen Status oder einen bestimmten Wert setzen oder abfragen. Was passiert sicher in 95% aller Fälle? Es wird ein String- oder Integer-Wert gesetzt oder verglichen. Aus meiner Sicht nicht besonders elegant und erst recht nicht sicher, da der Wert unnötig oft überprüft werden muss.

Mit Enums haben wir den Vorteil, dass wir bestimmte Werte vorgeben können und auch nur diese zu Verfügung stehen. Da wir unter PHP nur “normale” Klassen verwenden können, haben wir dadurch immer automatisch einen bestimmten Typen.

Wir wollen nun den Status eines Benutzers in unserem System definieren und legen uns dazu folgende Klasse mit den erforderlichen Werten an.

<?php
class UserStatus extends Custom_Enum
{
  const ACTIVE    = 1;
  const NOTACTIVE = 2;
  const DELETED   = 3;
}

Damit können wir unseren Benutzern einen eindeutigen Status setzen.

<?php
class User
{
  public function setStatus(UserStatus $status)
  {
    // ..
  }
}

$user = new User();

$status = new UserStatus();
$user->setStatus($status->active());

Durch das Type-Hinting können wir schon bei der Parameterübergabe den richtigen Objekttypen sicherstellen und müssen darauf später nicht mehr extra prüfen.

Die Klasse Custom_Enum funktioniert mit Reflektion und etwas PHP-Magie und ist bislang erst nur ein grober Entwurf. Ein paar Überprüfungen und eine bessere Fehlerbehandlung wären dann noch notwendige Maßnahmen.

<?php
abstract class Custom_Enum
{
  private $_constants;  // array
  private $_index;  // string

  public function  __construct()
  {
    $rc = new ReflectionClass($this);
    $this->_constants = $rc->getConstants();
  }

  public function __call($method, $args)
  {
    if (preg_match('/^is([a-zA-Z]*?)$/', $method, $matches)) {
      return $this->is($matches[1]);
    }
    $this->set($method);
    return $this;
  }

  public function __toString()
  {
    return (string)$this->getValue();
  }

  public function set($index)
  {
    $this->_index = strtoupper($index);
    return $this;
  }

  public function is($index)
  {
    return strtoupper($index) == $this->_index;
  }

  public function getValue()
  {
    return $this->_constants[$this->_index];
  }
}

Ich finde das schon wesentlich besser als lose String- oder Integerwerte auszutauschen, aber vielleicht geht es ja noch besser und sicherer? Eure Ideen, Kritik, Fragen oder was auch immer sind dann in den Kommentaren gut aufgehoben. Also keine Scheu und diskutiert mit!

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.