Die Funktionen call_user_func() oder call_user_func_array() fallen leider aus, da wir noch kein Callback-Objekt haben. Es gibt aber einen sehr einfachen Weg mit Reflections.

Zuerst ein paar einfache Klassen zum Testen. Von der Klasse Foo soll ein Objekt erstellt werden und diese erwartet je ein Objekt vom Typ Bar und Baz als Parameter im Konstruktor.

<?php
class Bar {}
class Baz {}

class Foo
{
  public function __construct(Bar $bar, Baz $baz)
  {
    echo '<pre>' . print_r(func_get_args(), true) . '</pre>';
  }
}

Nun wird das Objekt über eine sehr einfache Factory-Methode erzeugt und dabei wird die Parameterliste von create() an den Konstruktor weitergegeben.

<?php
class Factory
{
  public static function create($type)
  {
    $args = func_get_args();
    array_shift($args);
    $class = new ReflectionClass($type);
    return $class->newInstanceArgs($args);
  }
}

$foo = Factory::create('Foo', new Bar(), new Baz());

So einfach ist es. Über die Reflection-Klasse wird ein neues Objekt erzeugt.

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.

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.

Viele Fehler treten bei Magento schon durch eine fehlerhafte Konfiguration auf, was zur Folge haben kann, dass wir keine Instanz unser lokalisierten Klasse bekommen, sondern ein standard Magento-Objekt oder einen Fehler, weil keine passende Klasse gefunden wird.

So habe ich also angefangen, die Existenz der zu prüfenden Klassen zu testen und ob die Mage-Factory das gewünschte Objekt zurück gibt. Bei einigen Klassen ist es zudem auch noch wichtig, dass sie von der richtigen Elternklasse abgeleitet sind.

Da sich diese Tests immer wiederholten, zeichnete sich schnell ein Muster ab. Ebenso erfolgt auch die Namesgebung der Magentoklassen nach einem gewissen Muster. Was wäre also naheliegender, als beides miteinander zu verbinden und so in Zukunft eine Menge unnützer Schreibarbeit zu sparen?

Als erstes habe ich dafür einen erweiteren TestCase vom PHPUnit-TestCase abgeleitet, der mir weitere vereinfachte Asserts zur Verfügung stellt und die Tests dadurch auch etwas lesbarer macht.

$this->assertClassExists($classname);

statt

$this->assertTrue(class_exists($classname));

Auf diesem Wege lassen sich dann auch z.B. Getter und Setter einfach auf das gewünschte Standardverhalten prüfen.

Im nächsten Schritt habe ich einen Entity-TestCase abgeleitet, der als Basis für alle weiteren TestCases für Models, Blocks und Helper dienen soll. Dieser ist in sich schon ein wenig intelligenter und erkennt anhand des Namens der Test-Klasse, welche Klasse getestet werden soll, welchen Typ diese hat und welche die Standard-Elternklasse ist.

Diese Informationen werden, nebenbei bemerkt, durch protected Methoden ermittelt und könnten zu jeder Zeit durch noch speziellere TestCases wieder überschrieben werden.

Mit den nun vorliegenden Informationen ist diese TestCase-Klasse mächtig genug, um alleine durch Vererbung die grundlegenden Tests durchzuführen.

Für die jeweiligen Typen, z.B. Model habe ich dann noch weitere TestCases abgeleitet, um dort noch spezielle Methoden implementieren zu können.

Ein sehr einfacher Test für die Model-Klasse “Mein_Customer_Model_Customer” sähe dann beispielsweise so aus:

class Mein_Customer_Model_CustomerTest extends Mein_Model_TestCase
{
}

Dadurch würde nun automatisch getestet werden, ob der Autoloader die Klasse “Mein_Customer_Model_Customer” finden kann, diese von der Magento-Model-Klasse erbt und ob die Factory aufgrund der Konfiguration auch das richtige Objekt liefert.

Ich denke, dass es viel einfacher nicht mehr geht und das Argument gegen Tests damit dann auch aus der Welt sein sollte.

Kleiner Tipp: Wenn man es nun noch etwas konfortabler mag, dann kann man sich seine Models auch mit dem Zend_CodeGenerator bauen lassen und die Tests gleich mit.