Eine ausführliche Dokumentation mit vielen Beispielen findet ihr unter:
http://www.regular-expressions.info/unicode.html

Wer auch eines haben möchte, kann es sich kostenlos unter http://bit.ly/10TtZS bestellen.

Jedoch nicht als Programmierer. Also habe ich mir schnell ein kleines Programm in PHP geschrieben, welches eine Datei in 1 MB Blöcken kopiert und bei Fehlern diese einfach mit 0×00 Zeichen auffüllt. Ich poste es einfach mal, falls es jemand einmal brauchen kann

/**
 * Eine Datei kopieren und kaputte Sektoren überspringen
 */
 
 
define('BLOCKSIZE', 1024*1024); // 1 MB
 
 
if (count($argv) != 3) {
    showHelp();
}
else {
    copyFile($argv[1], $argv[2]);
}
 
function showHelp()
{
    echo "COPYIGNORE FROM TO\n";
}
 
function copyFile($from, $to)
{
    echo "Kopiere: $from => $to\n";
 
    if (!file_exists($from)) {
        die("$from nicht gefunden");
    }
 
    $handleFrom = fopen($from, "rb") or die ("$from konnte nicht geöffnet werden.");
    $handleTo = fopen($to, "wb") or die ("$to konnte nicht geöffnet werden.");
 
    $size = filesize($from);
    $c = 0;
    while ($c < $size) {
        $chunkSize = ($size - $c > BLOCKSIZE) ? BLOCKSIZE : $size - $c;
        $data = fread($handleFrom, $chunkSize);
        if ($data !== false) {
 
            fwrite($handleTo, $data);
 
            // Wenn wir einen Lesefehler finden mit 0x00 auffüllen und zum nächsten Block springen
            if (strlen($data) != $chunkSize) {
                fwrite($handleTo, str_pad('', ($chunkSize - strlen($data)), chr(0)));
                fseek($handleFrom, ($c+ $chunkSize)); // positionieren wo er sein sollte
                echo 'x';
            }
            else {
                echo '.';
            }
        }
        else {
            fwrite($handleTo, str_pad('', $chunkSize, chr(0)));
            echo 'x';
        }
        $c += $chunkSize;
    }
 
    fclose($handleFrom);
    fclose($handleTo);
    echo "done.\n";
}

Einige kennen Enums eventuell schon von Java. Sie sind eine Art objektorientierte Konstanten. Auf diese Weise kann man einer Methode typsichere Konstanten übergeben.

Hier mal ein Beispiel wie das sonst in der Regel aussieht:

class User
{
    public function setStatus($status)
    {
        // ....
    }
}

Der Nachteil ist ganz klar. Man kann jeden beliebigen Status übergeben. Also auch Zahlen oder Arrays. Und hier kommen die Enums ins Spiel. Wir definieren also eine Statusklasse:

class UserStatus extends CustomEnum
{
    const ACTIVE = 1;
    const NOTACTIVE = 2;
    const DELETED = 3;
}

Und damit können wir dem User nun einen OO-Status übergeben:

$user = new User();
$user->setStatus(UserStatus::ACTIVE());

Was mir an diesem Ansatz besonders gefällt ist, daß die Konstante noch als Konstante erkennbar ist und man auch die Unterstützung der IDE nutzen kann. Man muss lediglich die Klammern hinter die Konstante schreiben, da wir dafür eine Funktion verwenden. Auch die Schreibweise ist eher PHP-Style und damit intuitiver.

So dann will ich auch mal die aufgepeppte User-Klasse zeigen:

class User
{
    private $_status = null;
 
    public function setStatus(UserStatus $status)
    {
        $this->_status = $status;
 
        // Das hier ist nur Optional und um zu zeigen wie man den Status
        // auswerten kann
        switch ($status->ordinal()) {
            case UserStatus::ACTIVE()->ordinal():
                echo 'active';
                break;
            case UserStatus::NOTACTIVE()->ordinal():
                echo 'notactive';
                break;
            case UserStatus::DELETED()->ordinal():
                echo 'deleted';
                break;
        }
 
        echo($status->equals(UserStatus::ACTIVE())) ? 'active' : 'other';
    }
}

Die Namen für die Methoden der Enumklasse habe ich dabei der Java-Enumklassen entnommen.

So und nun kommen wir zum spannenden Teil. Wie sieht die CustomEnum Klasse eigentlich aus?

Den Konstruktor setzen wir private da die Klasse nur über die Konstantenmethoden instanziiert werden soll.
Ebenso lesen wir beim Erstellen der Klasse die Konstanten aus, da wir sie dann brauchen.

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

Die wichtigste Arbeit geschieht in der magischen Methode __callstatic(). Dort erzeugen wir ein neues Objekt und weisen ihm den Wert der Methode zu, was ja die Konstante repräsentiert.

    public static function __callstatic($method, $args)
    {
        $class = get_called_class();
        $enum = new $class();
 
        return $enum->_set($method);
    }

In der Set-Methode weisen wir den Wert zu (wer hätte das gedacht) und prüfen ob dieser Wert überhaupt gültig ist. Wenn nicht werfen wir eine Exception. Somit fallen fehlende Konstanten auch recht schnell auf.

    private function _set($index)
    {
        $this->_status = strtoupper($index);
        if (!isset($this->_constants[$this->_status])) {
            throw new UnexpectedValueException($this->_status . ' is not a valid value');
        }
        return $this;
    }

Das war auch schon fast die ganze Magie. Die Java-Klasse bietet noch die statische Methode values() welche alle verfügbaren Enumdefinitionen als Liste zurück gibt um darüber zu iterieren. Dafür müssen wir einen kleinen Kunstgriff machen. Wir erzeugen eine Klasse, damit wir alle Konstanten auslesen können. Für jede Konstante erzeugen wir noch ein Objekt und geben diese Liste zurück. Da wir den Namen der Klasse nur in einer Variablen haben, können wir an dieser Stelle nicht die statische Create-Methode nutzen. Deshalb müssen wir den Inhalt der __callstatic() in die __call() kopieren. Das finde ich zwar sehr unschön, aber mir ist keine bessere Lösung eingefallen.

    public static function values()
    {
        $list = array();
        $class = get_called_class();
        $enum = new $class();
 
        foreach ($enum->_constants as $name => $ordinal) {
            $list[] = $enum->$name();
        }
        return $list;
    }
 
    public function __call($method, $args)
    {
        $class = get_called_class();
        $enum = new $class();
 
        return $enum->_set($method);
    }

Die restlichen Methoden sind ja eher trivial. Und hier nun nochmal die gesamte Klasse in voller Schönheit.

abstract class CustomEnum
{
    /**
     * @var array
     */
    private $_constants = null;
 
    /**
     * @var string
     */
    private $_name;
 
    /**
     * Konstruktor soll nicht öffentlich aufgerufen werden.
     */
    private function __construct()
    {
        $rc = new ReflectionClass($this);
        $this->_constants = $rc->getConstants();
    }
 
    /**
     * Quasi der Konstruktor.
     *
     * @param string $method
     * @param mixed $args
     * @return CustomEnum
     */
    public static function __callstatic($method, $args)
    {
        $class = get_called_class();
        $enum = new $class();
 
        return $enum->_set($method);
    }
 
    public function __call($method, $args)
    {
        $class = get_called_class();
        $enum = new $class();
 
        return $enum->_set($method);
    }
 
    public function ordinal()
    {
        return $this->_constants[$this->_status];
    }
 
    public function name()
    {
        return (string) $this->_status;
    }
 
    public static function values()
    {
        $list = array();
        $class = get_called_class();
        $enum = new $class();
 
        foreach ($enum->_constants as $name => $ordinal) {
            $list[] = $enum->$name();
        }
        return $list;
    }
 
    public function __toString()
    {
        return $this->name();
    }
 
    private function _set($index)
    {
        $this->_status = strtoupper($index);
        if (!isset($this->_constants[$this->_status])) {
            throw new UnexpectedValueException($this->_status . ' is not a valid value');
        }
        return $this;
    }
 
    public function equals(CustomEnum $enum)
    {
        return $enum->_status == $this->_status && get_class($enum) == get_class($this);
    }
}

Diese Implementierung funktioniert jedoch nur ab PHP 5.3, weil erst dort die __callstatic() Methode eingeführt wurde.

An sich also eine tolle Sache. Nur die Frage ist, ob das auch performant ist oder ob es bessere Alternativen gibt.

Ronald Bradford hat in seinem Blog bereits darüber sinniert: To enum or not to enum?

So ergeben sich drei Argumente dagegen:

• Es ist kein SQL Standard und der Datentyp wird in anderen SQL-Datenbankensystemen teilweise anders behandelt oder implementiert
• Es besteht eine sehr enge Abhängigkeit zwischen der Datenbank und den Daten und es ist schwer Änderungen durchzuführen
• Die Behandlung von Gültigkeitsprüfungen der Daten sollte in der Anwendung geschehen

Ein großer Vorteil besteht aber darin, dass man in der Datenbank auch sofort sieht was drin steht. Weil die Alternativen sind, dass man es direkt als VARCHAR speichert. Dabei würden deutlich mehr Zeichen verbraucht, da ein ‘nein’ 4 Zeichen benötigt, das Mapping auf den internen Typ jedoch nur 1 Zeichen. Das stimmt so nicht ganz aber im Grundprinzip ist es so.
Eine andere Alternative wäre es ‘ja’ mit 1 zu kodieren und ‘nein’ mit 2. Dann braucht man entweder eine zweite Tabelle in der steht, welcher Wert was bedeutet und diese müsste man dann joinen. Das kostet natürlich Ressourcen.

Der MySQL PerformanceBlog hat einmal die verschiedenen Möglichkeiten der Umsetzung in Bezug auf die SELECT-Geschwindigkeit überprüft. Dabei hat sich gezeigt, dass der reine SELECT zwischen der Umsetzung als VARCHAR und der als ENUM kaum Unterschiede hat, ENUM ist einen kleinen Tick langsamer dabei.

Also ist ENUM in der Tat eine sinnvolle Lösung, wenn man eine Liste von möglichen Werten hat. Bei größeren Datenbanken spart man einfach Platz im Gegensatz zur VARCHAR Lösung. Und im Gegensatz zur Kodierung als INT sieht man einfach sofort welcher Wert repräsentiert wird und welche Werte möglich sind.

Aktuell gibt noch einen kleinen Bug, welcher auftritt, wenn man ein ENUM als utf8 kodiert. Dabei wird die ENUM-Spalte um 10-20% langsamer, als wenn man sie als latin1 kodiert. Aber da man die möglichen Werte sicher sowieso im normalen Bereich der 26 lateinischen Buchstaben hält, kann man da auch ohne Probleme beim latin1 bleiben.

Das hat mich interessiert und ich habe mal nachgeschaut warum dies geschehen ist, weil ich der Meinung war soviel Unterschied macht das eh nicht.

Hier mal der Beispielcode für einen Benchmark aus dem entsprechenden Issue:

echo '"is_null($var)" vs. "$var === null"' . "\n";
$max = 100000;
$varNull = null;
$varNotNull = true;
 
echo ' is_null($var): ';
$start = microtime(true);
for ($i = 0; $i < $max; $i++) {
    is_null($varNull);
    is_null($varNotNull);
}
$end = microtime(true);
echo($end - $start) . "\n";
 
echo ' $var === null: ';
$start = microtime(true);
for ($i = 0; $i < $max; $i++) {
    ($varNull === null);
    ($varNotNull === null);
}
$end = microtime(true);
echo($end - $start) . "\n";

Das Ergebnis dabei ist:

"is_null($var)" vs. "$var === null"
 is_null($var): 0.162046194077
 $var === null: 0.0550520420074

is_null ist also dreimal so langsam wie === null.

Ich habe den Test mal etwas verändert und habe mir die Frage gestellt, gibt es einen Unterschied zwischen === null und === NULL?

echo '"$var === nul"" vs. "$var === NULL"' . "\n";
$max = 100000;
$varNull = null;
$varNotNull = true;
 
echo ' $var === null: ';
$start = microtime(true);
for ($i = 0; $i < $max; $i++) {
    ($varNull === null);
    ($varNotNull === null);
}
$end = microtime(true);
echo($end - $start) . "\n";
 
echo ' $var === NULL: ';
$start = microtime(true);
for ($i = 0; $i < $max; $i++) {
    ($varNull === NULL);
    ($varNotNull === NULL);
}
$end = microtime(true);
echo($end - $start) . "\n";

Interessanterweise gibt es dabei noch immer einen messbaren Unterschied:

"$var === null" vs. "$var === NULL"
 $var === null: 0.0449469089508
 $var === NULL: 0.0551202297211

Ich habe den Test mehrmals durchlaufen lassen und das Erbenis war immer in etwa diesem Verhältnis.

Was ist eigentlich der Unterschied zwischen null und NULL? NULL ist eine Konstante mit dem Inhalt null. Die schnellste Variante ist also in der Tat === null. Besonders wenn man diese Prüfung in Schleifen durchführt kann sich das also schon etwas bemerkbar machen.

Und es gibt natürlich auch eine Möglichkeit bestehenden Code schnell mal damit zu optimieren:

find library/ -type f -name "*.php" -exec sed -i -r 's#([^\!])is_null\s*\(([^\(\)]*)\)#\1\2 === null#g' {} \;
find library/ -type f -name "*.php" -exec sed -i -r 's#[\!]is_null\s*\(([^\(\)]*)\)#\1 !== null#g' {} \;

Zuerst installieren wir xdebug über Aptitude, da dies xdebug auch gleich richtig für PHP konfiguriert:

apt-get install php5-xdebug

Nun müssen wir nun noch das Update auf die letzte Version anschieben:

pecl install xdebug

Falls man den Fehler

sh: phpize: command not found

bekommt, kann man dies durch

apt-get install php5-dev

beheben.

Die Fehlermeldung

sh: make: command not found

behebt man mit einem:

apt-get install make

Danach muss man jeweils nochmal xdebug über pecl installieren lassen!

Final sollte man den Apache noch einmal neu starten:

/etc/init.d/apache2 restart

Nachdem ich nun an einem (zugegebenermaßen unschönen) Beispiel gezeigt habe, wie so ein Container funktioniert möchte ich den Container aus dem Symfony Framework vorstellen. Zend hatte mal einen Container im Programm (zumindest im Labratory) jedoch wurde dieser wieder verworfen. Die genauen Hintergründe sind mir leider nicht bekannt. Ansonsten gibt es noch den einen oder anderen Container für PHP, jedoch macht Symfony mir in diesem Bereich den besten Eindruck. Von der Stabilität als auch von der Geschwindigkeit her. Er ist mit einer Code-Coverage von 100% getestet (das sagt noch nicht alles aus, aber schonmal, dass man da wirklich dahinter ist!). Und ansonsten lassen sich alle Konfigurationen und Zusammenstellungen zu 100% als PHP darstellen und kompilieren. Man kann also bei Bedarf die Unterstützung eines PHP-Opcode-Caches voll ausnutzen.

Auch hier wird ein Container verwendet. Das tolle ist aber, dass sich jeder aussuchen kann wie er seinen Container konfigurieren möchte. Man kann ihn direkt als PHP programatisch beschreiben. Oder mit INI-Dateien, mit XML-Dateien oder als YAML-Dateien. Und wenn der Container geladen ist, kann man ihn auch in jedes dieser Formate abspeichern egal wie man ihn geladen hat. Man kann so also wenn man maximale Performance will in der Entwicklung mit XML arbeiten und auf dem Live-System eine gespeicherte PHP-Konfiguration deployen.

Zuerst einmal wie eine Konfiguration von Hand ohne DI aussehen würde:

$transport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', array(
  'auth'     => 'login',
  'username' => 'foo',
  'password' => 'bar',
  'ssl'      => 'ssl',
  'port'     => 465,
));
 
$mailer = new Zend_Mail();
$mailer->setDefaultTransport($transport);

Und hier als Beispiel wir er im Symfony als XML konfiguriert wird:

<?xml version="1.0" ?>
 
<container xmlns="http://symfony-project.org/2.0/container">
  <parameters>
    <parameter key="mailer.username">foo</parameter>
    <parameter key="mailer.password">bar</parameter>
    <parameter key="mailer.class">Zend_Mail</parameter>
  </parameters>
  <services>
    <service id="mail.transport" class="Zend_Mail_Transport_Smtp"
shared="false">
      <argument>smtp.gmail.com</argument>
      <argument type="collection">
        <argument key="auth">login</argument>
        <argument key="username">%mailer.username%</argument>
        <argument key="password">%mailer.password%</argument>
        <argument key="ssl">ssl</argument>
        <argument key="port">465</argument>
      </argument>
    </service>
    <service id="mailer" class="%mailer.class%">
      <call method="setDefaultTransport">
        <argument type="service" id="mail.transport" />
      </call>
    </service>
  </services>
</container>

Man beachte, dass hier auch Variablenersetzung verwendet wird. So kann man den Benutzernamen auch mehrfach verwendet und dann schnell für alle Klassen ändern.

So wie wird der Spaß nun aber verwendet? Ganz einfach. Zuerst wird der Container erzeugt und mit der XML-Datei befüllt.

require_once '/PATH/TO/sfServiceContainerAutoloader.php';
sfServiceContainerAutoloader::register();
 
$sc = new sfServiceContainerBuilder();
 
$loader = new sfServiceContainerLoaderFileXml($sc);
$loader->load('/somewhere/container.xml');

Wenn man den Container nun als PHP-Datei speichern will um ihn schneller zu laden geht das wie folgt:

$dumper = new sfServiceContainerDumperPhp($sc);
$code = $dumper->dump(array('class' =>'Container'));
 
file_put_contents('/somewhere/container.php', $code);

Das ist aber nur optional.

Zugriff auf die Objekte holt man sich nun über:

$transport = $sc->getMailTransportService();
$mailer = $sc->getMailerService();

Ein ebenfalls sehr nettes Feature ist, dass man den Container auch als .dot-Datei ausgeben kann und mit dem dot-Programm in ein PNG-Bild konvertieren kann. Auf diese Weise hat man schnell einen Überblick über seine bestehende Anwendung und kann dies auch für die Dokumentation verwenden.

$dumper = new sfServiceContainerDumperGraphviz($sc);
file_put_contents('/somewhere/container.dot', $dumper->dump());

$ dot -Tpng /somewhere/container.dot > /somewhere/container.png

So damit hoffe ich nun einen guten Einblick in das Feld der DI und IoC gegeben zu haben. Und wie einfach und komfortabel man diese Pattern mit Symfony einsetzen kann.

Da ich DI und IoC auch jahrelang im Javaumfeld eingesetzt habe und es nun auch in PHP nun ausprobiert habe, kann ich sagen, dass es eine feine Sache ist. Grundsätzlich ist es ein wenig Mehraufwand. Die so oft hochgehaltene Flexibilität tritt in der Praxis aber eher nie ein. Weil bei einem Ansatz ohne DI kann man sich Stück für Stück seine Klasse aufbauen. Bei DI muss man sie konfigurieren. Bei jeder Änderung fasst man die Klasse als auch die Konfigurationsdatei an. Ebenso bekommt man damit einen Single-Point-of-Failure. Wenn die Konfigurationsdatei kaputt geht geht im Zweifel gar nix mehr. Ebenso arbeiten so alle Teammitglieder an der Konfigurationsdatei, was zu häufigeren Merges führen kann. Dies kann man jedoch durch aufteilen in mehrere Konfigurationsdateien und entsprechende Includes verringern. Bleibt noch der Aufwand, das man jedesmal zwei Dateien anfasst anstatt nur eine. Soweit zu den negativen Aspekten. Die Vorteile sind aber auch sehr deutlich. Jeder weiß wo er schauen muss wenn ein Logger oder eine Klasse konfiguriert werden soll. Kein Wühlen mehr durch viele Bootstrap und Konfig-Klassen oder gar durch die halbe Anwendung. Man hat einfach Ordnung. Man kann Anwendungsweit einen Logger schnell mal aktivieren oder deaktivieren. Man kann durch ein geschicktes Deployment konfigurativ auf einem Live-System einen Debugger deaktivieren ohne in der Entwicklung irgend etwas verändern zu müssen. In der Entwicklungsumgebung hat man also weiterhin seine Debugausgaben.

Das ganze ist also auf jeden Fall ein guter Schritt in Richtung saubere Architektur, weil es eine Menge kleiner Schweinereien die man so gerne macht unterbindet. Und aus diesem Grund gehört dieses Pattern ab einer gewissen Projektgröße eigentlich zu den Must-Haves.

In meinem ersten Artikel habe ich gezeigt was Inversion of Control (IoC) und Dependency Injection (DI) sind und warum sie so gut sind.

Nachdem ich so viel positive und konstruktive Kritik bekommen habe, habe ich diese natürlich auch in diesen Artikel einfließen lassen. Ich werde nun also am Anfang noch einmal kurz den Unterschied zwischen IoC und DI erklären. Danach werde ich anhand einer einfachen Beispiel-Implementierung zeigen wie DI implementiert werden kann. Im dritten Teil werde ich dann auf die DI von Symfony 2.0 eingehen.

Unterschied zwischen Inversion of Control (IoC) und Dependency Injection (DI)

Bei der Unterscheidung halte ich mich an Martin Fowler.

Wenn man Inversion of Control einsetzt nennt man diese lose gekoppelten Klassen Komponenten und Services. Komponenten sind dabei eher “dummy” Objekte, die Logik beinhalten aber nicht direkt mit anderen Systemen kommunizieren. Deren Aufgabe ist also hauptsächlich die Berechnung von Daten oder Kapselung von Logik. Services interagieren fleissig mit anderen Services oder Komponenten. Inversion of Control bezeichnet dabei einfach nur, dass die Abhängigkeiten nicht fest einprogrammiert sind, sondern von außen eingeimpft werden. IoC beschreibt also einfach das grundsätzliche Paradigma.

Dependency Injection hingegen beschreibt wie diese Abhängigkeiten gesetzt werden. Beim letzten Mal habe ich bereits auf die Möglichkeit hingewiesen, dass diese Abhängigkeiten über Konstruktoren gesetzt werden können oder aber auch über Setter-Methoden.

In einer Präsentation von Fabien Potencier wird noch die Property-Injection genannt. Dies ist ganz einfach

$myClass = new MyClass();
$myClass->logger = $logger;

Kann man machen muss man aber nicht. Vor allem sollte man das gar nicht. Öffentliche Eigenschaften sind im Sinne der OO sehr unschön und führen zu vielen Seiteneffekten. Also vergessen wir das auch mal ganz schnell wieder.

Eine weitere von Fowler gezeigte Möglichkeit ist die Interface Injection. Hier mal ein kleines Beispiel

interface MyClassInterface {
    function setLogger(Zend_Log_Writer_Abstract $logger);
}

Es soll hierbei mal egal sein ob Zend gut oder schlecht oder besser als etwas anderes ist. Zend_Log_Writer_Abstract ist einfach eine Abstrakte Oberklasse von der es noch weitere konkrete Implementierungen gibt. Da MyClass dieses Interface implementiert bekommt sie automatisch die Abhängigkeit zu diesem Logger gesetzt. MyClass kommt also gar nicht in die Verlegenheit sich selber einen Logger zu suchen.

Interface Injection ist nicht ganz trivial und man muss es sich eine Weile durch den Kopf gehen lassen. Während die anderen Typen der DI eher konkrete Umsetzungen definieren, so definiert Interface Injection eher ein Pattern.

Beispielimplementierung eines Containers zur Verwendung eigener Dependency Injection

Da wir nun wissen, dass es besser ist, dass Abhängigkeiten von außen gesetzt werden wollen wir einmal schauen wie das am besten geht.

Ohne IoC haben wir einfach folgendes gemacht:

$myClass = new MyClass();

MyClass hat sich dann die Datenbankverbindung und den Logger selber geholt. Mit IoC müssten wir so etwas schreiben:

$dbHandle = new Zend_Db_Adapter_Pdo_Mysql(array(
    'host'     => '127.0.0.1',
    'username' => 'webuser',
    'password' => 'xxxxxxxx',
    'dbname'   => 'test'
));
$logger = new Zend_Log();
$myClass = new MyClass();
 
$myClass->setDbHandle($dbHandle);
$myClass->setLogger($logger);

Und das an allen Stellen im Code wo wir MyClass verwenden wollen. Nicht sehr schön und so bringt das auch keine Vorteile. Viel schöner wäre es, wenn es eine Instanz geben würde, die weiß wie sie all diese Komponenten zusammen bauen muss. Wo ich einfach nur noch sage: Gib mir eine frische MyClass.

Na dann fangen wir an…

Das Grundkonzept ist, dass man eine Art Registry hat wo man sich seine Objekte abholt. Konkret wird diese Registry als Container bezeichnet.

Zuerst definieren wir einmal wie unsere Applikation aussehen soll:

$classDefinition = array(
    'Action_Admin_Login' => array(),
    'Action_Game_Login' => array(),
 
    'Controller_Model_Admin' => array(),
    'Controller_Rpc' => array(),
 
    'View_Admin_Login' => array(),
    'View_Admin_Main' => array(
        'Controller_Main'),
    'View_Admin_UserGroupList' => array(
        'Controller_UserGroupList'),
    'View_Admin_UserGroupListModify' => array(
        'Controller_UserGroupList'),
    'View_Admin_UserList' => array(
        'Controller_UserList'),
    'View_Admin_UserShow' => array(
        'Controller_UserShow'),
 
    'View_Game_Main' => array()
);

Dies ist ein einfaches Array, wo jede Klasse die wir konfigurieren als Schlüssel definiert wird. Als Wert hinterlegen wir ein Array mit Namen von Objekten die wir in der Klasse setzen wollen. Dies wird ein sehr einfacher Container, deshalb verwenden wir hier Setter-Injection. Ebenso können unsere Klassen nicht mit Parametern konfiguriert werden. Aber es geht hier auch nicht um einen Container für den Produktiveinsatz sondern um das grundlegende Konzept zu demonstrieren.

Wir haben nun also unsere Registry, welche noch recht leer ist:

class Registry
{
 
    public static $classDefinition = array();
 
    public static function getInstance ($className)
    {
         // @todo
    }
 
}

Dann füllen wir mal die getInstance mit Leben…

        array_push(self::$stack, $className);

Wir legen den Klassennamen auf den Stack. Dies ist notwendig da wir ja eventuell komplexere Bäume laden. Ebenso bauen wir einen Hash auf, welche Klassen wir gerade instanziieren um Schleifen zu erkennen und abzubrechen. Wenn wir also eine Schleife erkennen brechen wir ab.

        if (isset(self::$hashStack[$className])) {
            die('Loop in Objektinstanziierung.');
        }
        self::$hashStack[$className] = true;

Damit ein Objekt nicht jedesmal neu erzeugt werden muss cachen wir es in der Klassenvariablen $object. Wenn das Objekt also noch nicht existiert erzeugen wir es.

Dabei laden wir alle Klassen die wir brauchen. Diese laden wir rekursiv über getInstance(). Wir gehen davon aus, dass für alle Objekte entsprechende Setter- und Getter-Methoden existieren und setzen das Objekt darüber. Am Ende cachen wir es lokal.

        if (! isset(self::$objects[$className])) {
 
            $injection = self::getClassDefinition($className);
            if (is_array($injection)) {
                $obj = new $className();
 
                foreach ($injection as $tempClassName) {
                    $setterFunction =
self::getSetterFunctionForClassName($tempClassName);
                    $tempObj = self::getInstance($tempClassName);
                    $obj->$setterFunction($tempObj);
                }
 
                self::$objects[$className] = $obj;
            }
        }

Nun noch die Stacks aufräumen und das fertige Objekt zurück geben.

        unset(self::$hashStack[$className]);
        array_pop(self::$stack);
 
        return self::$objects[$className];

Das war auch schon die Implementierung der getInstance(). Der Vollständigkeithalber hier noch die getSetterFunctionForClassName-Methode. Dabei werden einfach die Unterstriche entfernt und ein “set” davor gehangen.

    private static function getSetterFunctionForClassName ($className) {
        $functionName = str_replace('_', '', $className);
        return 'set' . $functionName;
    }

Ich hoffe damit das Grundlegende Konzept eines Containers verständlich erklärt zu haben. Im dritten und letzten Teil werde ich dann Dependency Injection im Symfony 2.0 Framework vorstellen.