Archiv

Archiv für die Kategorie ‘Pattern’

Enums in PHP

8. Oktober 2010 Sven 2 Kommentare

Durch den Artikel von Daniel inspiriert habe ich auch mal etwas mit Enums herumgespielt. Aber eins nach dem anderen…

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.

KategorienPattern, PHP Tags:

Inversion of Control – Teil 3 – Dependency Injection im Symfony 2.0 Framework

9. Juli 2010 Sven 1 Kommentar

So da nun auch Teil 3 auf PHP hates me veröffentlicht wurde (danke nochmal an Nils) hier nun auch nochmal die Veröffentlichung in meinem Blog ;)

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.

KategorienAllgemein, Pattern Tags:

Inversion of Control – Teil 2

9. Juli 2010 Sven Keine Kommentare

So da nun auch Teil 2 auf PHP hates me veröffentlicht wurde (danke nochmal an Nils) hier nun auch nochmal die Veröffentlichung in meinem Blog ;)

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.

KategorienPattern, PHP Tags:

Inversion of Control

27. Mai 2010 Sven Keine Kommentare

Heute ist mein Artikel Inversion of Control auf PHP hates me erschienen. Danke nochmal an Nils, dass er mir diese Plattform geboten hat um meine Artikel auch einem größeren Publikum zugänglich zu machen. Ansonsten als Futter für die Suchmaschine hier nochmal der komplette Artikel.

Viele haben sicher schon einmal etwas von Inversion of Control (IoC) und
Dependency Injection (DI) gehört. Und sicher auch, dass es ganz toll ist
und es zu den best practices gehört. Nur eine Frage die oft nicht wirklich
beantwortet wird: Wieso ist das so sinnvoll?

Ich versuche hier einmal diese Frage mit einem Beispiel aus dem realen
Leben zu dokumentieren und zu beantworten…

Wir stellen und eine größere mittelständige Firma vor. Sie hat mehrere
Abteilungen die eigenständig arbeiten. Natürlich müssen da auch Dinge
angeschafft werden und das kostet Geld. Entsprechend ihrem Bedarf
bestellen diese Abteilungen also Dinge wie Drucker, Computer oder
Spezialhardware. Die Rechnungen werden in die Buchhaltung gegeben und dann
von dort aus bezahlt.

Das KANN alles super funktionieren. Aber nur dann, wenn diese Abteilungen
auch verantwortungsbewusst mit Geld umgehen und nur Dinge anschaffen, die
sie wirklich benötigen. Außerdem ist es schwer einen
Abteilungsübergreifenden Überblick zu bekommen, welche Hardware vorhanden
ist. Es kann auch passieren, dass mehrere Abteilungen die selbe
Spezialhardware bestellen obwohl sie sich diese eigentlich hätten teilen
können. Auch ist es schwer nachzuvollziehen wo denn das ganze Geld
geblieben ist.

Wie kann man diesen Zustand also optimieren? So wie es in der Praxis oft
gehandhabt wird: Die Abteilungen melden am Anfang eines Jahres ihren
Bedarf an, daraus wird ein Gesamtbedarf ermittelt und ein Jahresbudget
errechnet. Das wird dann angepasst und optimiert und jeder Abteilung ein
Budget, welches sie zur Verfügung haben, mitgeteilt. Größere Anschaffungen
müssen jedoch erst genehmigt werden (damit kann man doppelte Einkäufe
teurer Spezialhardware vermeiden). Und da diese größeren Anschaffungen nur
noch von einer zentralen Stelle vorgenommen werden hat man darüber auch
immer einen Überblick.

Und Dinge die sich so im Alltag bewährt haben machen auch beim
Softwaredesign Sinn. Wieso soll sich eine Klasse Gedanken machen woher sie
ihren Logger bekommt? Oder wo sie einen Zugang zur Datenbank findet? Das
ist gar nicht ihre Aufgabe. Es ist viel sinnvoller einer Klasse einfach
einen Logger oder eine Datenbankverbindung an die Hand zu geben und sie
macht das was sie am besten kann. Ihre eigene Logik zu implementieren.

Soweit die graue Theorie. Ich hoffe ich habe nun alle (oder zumindest
viele) von dem Nutzen der IOC und DI überzeugen können. Denn nun möchte
ich zeigen, wie die Umsetzung dessen in der Praxis aussehen kann.

Hier der bisher unschöne Weg wie eine Klasse Ressourcen verwendet:

class MyClass
{
 
    private $_logger;
    private $_dbHandle;
 
    function __constructor()
    {
        $this->_logger = Zend_Registry::get('LOGGER');
        $this->_dbHandle = Zend_Registry::get('DB');
    }
 
    function doSomething()
    {
        // etwas loggen
        $this->_logger->write('foo');
 
        // Daten aus der Datenbank lesen
        $this->_dbHandle->select('SELECT * FROM bar');
    }
}

Die Klasse holt sich im Konstruktor selber ihre Abhängigkeiten und
verwendet sie dann.

Besser ist folgender Ansatz:

class MyClass
{
    private $_logger;
    private $_dbHandle;
 
    function __constructor()
    {
    }
 
    function setLogger(Zend_Log_Writer_Abstract $logger)
    {
        $this->_logger = $logger;
    }
 
    function setDbHandle(Zend_Db_Adapter_Abstract $dbHandle)
    {
        $this->_dbHandle = $dbHandle;
    }
 
    function doSomething()
    {
        // etwas loggen
        $this->_logger->write('foo');
 
        // Daten aus der Datenbank lesen
        $this->_dbHandle->select('SELECT * FROM bar');
    }
 
}

Die Klasse bekommt ihre Abhängigkeiten über Setter-Funktionen gesetzt. Man
kann an dieser Stelle die Setter natürlich auch zugunsten von
Konstruktor-Parametern ersetzen. Ein offensichtlicher Vorteil ist schon
einmal, dass die Klasse sich nicht überlegen muss WOHER sie den Logger
oder das DB-Handle bekommt. Der Zugriff über eine Registry ist nichts
weiter als eine objektorientierte Form von globalen Variablen. Wenn sich
der Zugriffsbezeichner ändert, müssen alle Klassen angepasst werden. Ebenso
ist der Rückgabewert einer solchen Registry nicht Typsicher. Dieses Problem
haben wir über die Setter-Funktionen gelöst.

Soweit möchte ich hier erst einmal Schluss machen für diesen Artikel. Im
nächsten Artikel möchte ich dann einmal zeigen, wie man sehr einfach diese
Dependency Injection umsetzen kann.

KategorienPattern, PHP Tags: