Abhängigkeiten Komponieren in PHP

logo composer transparentProblem?

Wie verwendet man eigentlich Fremd-Bibliotheken im eigenen PHP Projekt? Um Probleme zu vermeiden liefert man diese lieber selbst und stellt sie in seiner Verzeichnisstruktur zu Verfügung. Verbunden mit einigen Nachteilen: Das Projekt wird größer (z.B. durch den Einbau von riesigen Bibliotheken wie ORMs) und das Gerangel verschiedener Autoloader wird unperformant und unübersichtlich. Letzten Endes ist die Bibliothek grundsätzlich veraltet und als Author ist man selbst für Updates verantwortlich. Als Alternative hat man hier noch PEAR. Damit stößt man bei Produktivsystem schnell an seine Grenzen: Include Pfade, Dev und Beta Channels verhindern flüssiges Arbeiten und man hat schnell eine kaputte Umgebung die nicht mehr so arbeitet wie man eigentlich wollte.

Ich bin neulich über den Composer gestolpert und hab ihn prompt lieb gewonnen. Projekt-Lokale Installation, einfach Konfiguration und nicht zuletzt eine gute Webseite machen den Einstieg leicht. Am besten ich zeige was ich meine

Konfiguration

Im Projekt selbst wird eine composer.json angelegt:

{
  "require": {
    "twig/twig": "1.11.*",
    "pimple/pimple": "1.0.*"
  }
}

Hier wird kurz beschrieben was man für sein Projekt benötigt. Die Konfiguration bietet natürlich noch einiges mehr. Grundsätzlich reicht das Snippet von oben aber aus.

Installation Composer

$ curl -s https://getcomposer.org/installer | php
#!/usr/bin/env php
All settings correct for using Composer
Downloading...
Composer successfully installed to: /data/tmp/test-projekt/composer.phar
Use it: php composer.phar

That’s it. Falls etwas fehlt, wird man freundlich darauf hingewiesen und man kann die Änderungen nachreichen.

Auflösen der Abhängigkeiten

$ php composer.phar install
Loading composer repositories with package information
Installing dependencies
  - Installing twig/twig (v1.11.1)
    Loading from cache
  - Installing pimple/pimple (v1.0.1)
    Loading from cache
Writing lock file
Generating autoload files

Auch das ging schon fast zu schnell. Wir sind fertig.

Einbinden in den eigenen Code

Der Composer legt im Projekt ein Verzeichnis “vendor” mit einem eigenen Autoloader an. Der muss nur noch inkludiert werden:

<?php
require 'vendor/autoload.php';
// OWN PROJECT

Der Autoloader des Composers kann auch gleich für das eigenen Projekt genutzt werden und beherrscht alle Vorgaben aus dem PSR-0 Standard. Die JSON Datei erhält hierfür eine weitere Konfiguration:

{
    "autoload": {
        "psr-0": {
            "NETWAYS": "lib/",
            "OTHER_NAMESPACE": "lib/",
        }
    }
}

Fazit

Schnell, einfach und leicht. Diese Devise wird vom Composer aufgegriffen und konsequent umgesetzt. Einziges Manko: Man braucht mindestens PHP 5.3.2. Das sollte allerdings schon bis in die letzten staubigen Ecken vorgedrungen sein. Weitere Informationen finden man auf der Webseite oder im Paketverzeichnis.

Ein guter Vorsatz für das bevorstehende neue Jahr – Ich wünsche einen guten Rutsch!

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Man reiche mir einen Pimple!

Die genaue Übersetzung des Begriffes “Pimple” ist eher unappetitlich und hat auch nichts mit einem fränkischen Gummistöpsel zum reinigen von Toiletten oder ähnlichem zu tun. Es handelt sich eher um einen Dependency Injection (DI) Container für PHP5.3 welcher dafür zuständig ist, Objekte für den Gebrauch in der Applikation bereitzustellen und an einer zentralen Stelle aufzubewahren.
DI ist ein Entwurfsmuster und zielt damit auf ein Paradigma aus der objektorientierten Programmierung ab, welches eine “Steuerungsumkehr” vorschreibt (IoC = Inversion of Control). Mit diesem Muster baut eine Klasse seine Abhängigkeit nicht selbst sondern bekommt diese injiziert. Damit muss die Klasse die konkrete Implementierung nicht selbst kennen, lediglich die darauf aufbauende Schnittestelle.
Ein Beispiel aus der Zeit wo Mark Zuckerberg noch Erich Mielke hieß:

store = new SessionStorage("DING");
        }
        public function writeToDump() {
                $this->store->store((array) $this);
        }
        public function __destruct() {
                $this->writeToDump();
        }
}
class User {
        public function __construct() {
                $this->session = new Session();
                $this->session['authenticated'] = false;
        }
        public function setAuthenticated() {
                $this->session['authenticated'] = true;
        }
}

Diese Vorgehensweise wird zum Problem wenn die Klasse “Session” öfters verwendet wird – und das wird der Fall sein. Man kann sie nicht einfach ersetzen. Entweder schmeißt man die bisherige Implementierung über Board oder muss im kompletten Code die Handhabung anpassen um mit der neuen Implementierung umzugehen. Idealer Anwendungsfall sind UnitTests. In diesem Fall könnte man eine Dummy-Session schreiben (Mock-Objekt) welche die Daten einfach verwirft, da dies für den Test nicht relevant ist (Oder zum Fehler führt da in der Testumgebung eventuell kein valider Cookie Container existiert).
Um dem Herr zu werden bauen wir das ganze um und geben die Implementierung mit (Constructor Injection):

store = $s;
        }
        public function writeToDump() {
                $this->store->store((array) $this);
        }
        public function __destruct() {
                $this->writeToDump();
        }
}
class User {
        public function __construct(ISession $session) {
                $this->session = $session;
                $this->session['authenticated'] = false;
        }
        public function setAuthenticated() {
                $this->session['authenticated'] = true;
        }
}

Jetzt muss beim instantiieren immer ein gültiges Session Objekt mit zugegeben werden was “einiges” an Verdrahtungsarbeitet kostet. Die Implementierung kann aber leichter ausgetauscht werden. Konfigurierbar ist dieses Vorgehen aber noch nicht und kostet daher weiterhin Wartungsaufwand wenn Änderungen durchgeführt werden müssen.
Jetzt wird es Zeit für Pimple. Wir konfigurieren uns einen Container und kleben die Implementierung zur Laufzeit zusammen:

$session = new Pimple();
// Konfigurationsanteil
$session['cookie_name'] = 'DING';
$session['session_storage_class'] = 'SessionStorage';
$session['session_class'] = 'Session';
$session['session_storage'] = function($c) {
        return new $c['session_storage_class']($c['cookie_name']);
};
$session['session'] = $session->share(function($c) {
        return new $c['session_class']($c['session_storage']);
});

Zwecks besserer Übersicht sind die Schnittstellen und Klassen raus gelassen. Mit dem obigen Beispiel kan man zur Laufzeit alles erdenkliche steuern und die Container-Klasse als Provider beliebig in der Applikation verwenden. Für eine neue Session oder einen Storage-Provider, tauscht man die Implementierung per Konfiguration aus – fertig!
Man könnte sogar noch weiter gehen und die Konfiguration in XML oder INI Dateien verpacken. Allerdings mit dem Nachteil in der Konfiguration zu “programmieren” was das Konstrukt zerreist und bei großen Projekten zur Unübersichtlichkeit führt.
Bei Compilersprachen wird dieses Feature für mehr Flexibilität benutzt um Austauschbarkeit zur Laufzeit zu erreichen. Bei Scriptsprachen hingegen gibt es oft eigene (sehr eigene ;-)) Möglichkeiten, Methoden zu überschreiben oder irgendwelche Wrapper einzubinden.
Natürlich ist DI nicht die einzige Möglichkeit. Einige dieser Patterns, z.B. “Service/Locator”, “Observer”, Fasaden, … zielen auf IoC ab. Auch Singletons könnte man dazu zählen – Sollte man aber nicht.
Natürlich ist alles nicht immer nur mit Vorteilen verbunden. Man muss also genau abwägen in wie weit einem dies nützt und bei der Durchführung eines Projekts unterstützt. Auch darf man es, wie bei allen Pattern, nicht zu sehr übertreiben. Für die Ausgabe von drei Zeilen Text muss ich keine 20 Paradigmen aufgreifen um guten Code zu schreiben.
Die positive Seite der Medaille: Der Code wird wandelbarer und damit leichter zu warten!

PimpleInversion of ControlSubstrate – PHP5/SPL

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.