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);
  }
}

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