Nun habe ich in der Vergangenheit ja schon das eine oder andere über Closures in PHP und Java Comparatoren für PHP geschrieben und wollte das nun mal zusammenbringen.

Einige PHP-Sortierfunktionen erlauben Callbacks, um die Reihenfolge zu bestimmen. Da ich das Ganze aber gerne in gut testbaren OOP-Einheiten hätte, müssen wir einen kleinen Umweg gehen.

Zunächst das obligatorische Interface.

namespace E7;

interface Comparator {
  public function compare($a, $b);
}

Diese Schnittstelle implementieren wir mit einer abstrakten Klasse.

namespace E7;

class BaseComparator implements Comparator {
  public function compare($a, $b) {
    if ($a == $b) { return 0; }
    return $a < $b ? -1 : 1;
  }

  public function __invoke() {
    return call_user_func_array(array($this, 'compare'), func_get_args());
  }
}

Und schon haben wir einen einfachen, und zugegebenermaßen nicht typsicheren, Comparator.

Durch die magische Methode __invoke() kann ein Objekt nun wie eine Callbackfunktion verwendet werden.

Für die Sortierung von Objekten kann das dann einfach erweitert werden.

class PersonComparator extends BaseComparator {
  public function compare($a, $b) {
    // hier Prüfung auf Typ etc.
    return parent::compare($a->getId(), $b->getId());
  }    
}

Um die Sortierreihenfolge negieren zu können, können wir einen einfachen Wrapper nutzen.

class ReverseOrder implements Comparator {
  private $_comparator;

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

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

Beispiel…

//--
$people = array();
for ($i = 0; $i < 10; $i ++) {
  $people[] = new Person();
}

echo 'BEFORE<br/>';
foreach($people as $person) {
  echo "$person<br/>";
}

$comparator = new ReverseOrder( new PersonComparator() );

uasort($people, function($a, $b) use ($comparator) {
    return $comparator->compare($a, $b);
});

// oder

uasort($people, $comparator);

echo 'AFTER<br/>';
foreach($people as $person) {
  echo "$person<br/>";
}

Bislang musste man Callback-Funktionen gewöhnlich definieren, bevor man sie verwenden konnte.

<?php
function myCallback($output) {
  return '##' . $output . '##';
}

echo call_user_func('myCallback', 'Hallo Welt');

// Ausgabe:
##Hallo Welt##

Als Closure geschrieben sähe das dann so aus:

<?php
echo call_user_func(
  function($output) { return '##' . $output . '##'; },
  'Hallo Welt');

// Ausgabe:
##Hallo Welt##

Zugegeben, dieses Beispiel hätte man durch einfache Stringverkettung wesentlich einfacher schreiben können und eigentlich war das mit create_function() auch schon unter PHP4 möglich.

Wir können die Funktion natürlich wie früher auch schon in einer Variablen speichern und dann weiter verwenden.

<?php
$myFunction = function($output) {
  return '##' . $output . '##';
};

echo call_user_func($myFunction, 'Hallo Welt') . '<br/>';
echo $myFunction('Hallo Welt') . '<br/>';

//Ausgabe:
##Hallo Welt##
##Hallo Welt##

Und auch das ist ja noch nichts Neues. Mit Closures haben wir nun aber auch die Möglichkeit, teile unserer “Umgebung” zum Zeitpunkt der Funktionsdefinition zu konservieren.

Dazu müssen wir nur die Definition etwas erweitern.

<?php
$before = '>';
$after = '<';

$myFunction = function($output) use ($before, $after) {
    return $before . $output . $after;
};

echo $myFunction('Hallo Welt') . '<br/>';

//Ausgabe:
>Hallo Welt<

An dieser Stelle frieren wir mit “use” sozusagen die Werte für $before und $after innerhalb unserer Funktion ein. Spätere Änderungen der beiden Variablen haben keine Auswirkungen auf die Funktion.

$before = 'foo';
$after = 'bar';
echo $myFunction('Hallo Welt') . '<br/>';

//Ausgabe:
>Hallo Welt<

In PHP wir mittlerweile sehr viel mit Standardinterfaces und -klassen (SPL) abgedeckt und so ist es auch in diesem Fall. In der Variablen $myFunction ist ein Objekt vom Typ “Closure” gespeichert.

<?php
echo '<pre>' . print_r($myFunction, true) . '</pre>';

//Ausgabe:
Closure Object
(
  [static] => Array
    (
      [before] => >
      [after] => <
    )
  [parameter] => Array
    (
      [$output] =>
    )
)

Will man eigene Objekte wie Funktionen aufrufen, dann geht das mit der magischen Methode __invoke(), die auch hier verwendet wird.

Anfangs erwähnte ich, dass Closure-Callbacks zur Filterung, aber auch zur Manipulation von Array verwendet werden können.

Wenn nur der Inhalt interessant ist, dann kommen wir mit array_map() und einem Parameter aus.

<?php
$values = array(
  array(
    'a' => array(
      'b' => 'foo'
    )
  ),
  array(
    'a' => array(
      'b' => 'bar'
    )
  ),
);

$filtered = array_map(
  function ($item) { return $item['a']['b']; },
  $values
);
echo '<pre>' . print_r($filtered, true) . '</pre>';

// Ausgabe:
Array
(
  [0] => foo
  [1] => bar
)

Wollen wir aber Werte im Array in Abhängigkeit zum Key/Index verändern, dann geht das mit array_walk und einem zweiten Parameter im Callback. Bei beiden kann natürlich auch “use” verwendet werden. Der Parameter $value wird dabei als Referenz übernommen.

$values = array(
  'a' => 100,
  'b' => 200,
  'c' => 300,
);

array_walk(
  $values,
  function (&$value, $key) {
    if ('b' == $key) {
      $value = 42;
    }
  }
);

echo '<pre>' . print_r($values, true) . '</pre>';

// Ausgabe:
Array
(
  [a] => 100
  [b] => 42
  [c] => 300
)

Ich hoffe, dass ich ein wenig Licht ins Dunkel bringen konnte und “Closure” nun kein geheimnisvolles Zauberwort mehr ist.

Wenn ihr noch gute Ergänzungen oder Anwendungbeispiele habt, dann immer her damit und bitte fleissig kommentieren.

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.

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?

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…

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

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.