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.

Häufig kommt es vor, dass diese drei Muster aufgrund gewisser oberflächlicher Ähnlichkeiten verwechselt oder pauschal zum Decorator gemacht werden.

Dabei verfolgen alle drei doch recht unterschiedliche Ziele und die will ich heute möglichst kurz gegenüberstellen.

Zunächst klären wir erstmal was die drei gemeinsam haben. Alle drei Muster kontrollieren den Zugriff auf ein Objekt.

Decorator

Das wichtigste Merkmal eines Decorators ist, dass er den Typ des zu dekorierenden Objektes nicht verändert. Wollen wir also ein Animalobjekt dekorieren, dann muss unser Dekorierer von Animal erben und alle Methodenaufrufe an das in ihm gekapselte Objekt delegieren.

Beim Weiterleiten der Methodenaufrufe kann nun das Verhalten verändert werden und das ohne Vererbung zur Laufzeit.

Methoden können quasi abgeschaltet werden, indem sie nicht weiterleiten. Andere Methoden könnten die Werte vor dem Weiterleiten verändern. Auch neue, zusätzliche Methoden sind möglich.

Beispiele

• Streams (in Java)
• Verändern von GUI-Elementen

Adapter

Im Gegensatz zum Decorator verändert der Adapter gewollt den Typ des gekapselten Objektes. Das Muster eignet sich, um bestehende Komponenten an eine neue Schnittstelle anzupassen.

Wenn sich die Katze also wie eine Kuh verhalten soll…

class CatToCowAdapter extends Cow {
  private Cat cat;

  // andere Methoden

  public void muh() {
    this.cat.miau();
  }
}

Proxy

Ein Proxy ist ein Stellvertreter für die “echten” Objekte, wenn diese zum Beispiel nicht sofort verfügbar sind oder nicht alle Ressourcen freigeben dürfen. Soll zum Beispiel ein Bild in einer GUI-Anwendung über das Netzwerk geladen werden, würde das ggf. die Anwendung während der Ladezeit ausbremsen.

Ein ImageProxy könnte in einem eigenen Thread auf das Bild warten und in der Zwischenzeit eine Ersatzgrafik anzeigen (animierte Sanduhr etc.).

Über Proxy-Objekte lässt sich auch der Zugriff auf Datenstrukturen kontrollieren. Dabei würde der Proxy kontrollieren, wem das Datenobjekt gehört und nur die dementsprechenden Lese- und Schreibzugriffe erlauben.

Beispiele

• Laden von Ressourcen
• Kontrollieren von Daten