• Das Singleton ist ein sehr leicht zu verstehendes Design Pattern, selbst für Programmierer die sich neu mit dem Thema Design Patterns befassen bzw. überhaupt erst kurze Zeit mit objektorientierter Programmierung vertraut sind.
• Das Singleton löst ein Problem, das 99% dieser Programmierer haben, nämlich einen globalen Zugriffspunkt auf eine Klasse bereitzustellen, die überall in einer Anwendung genutzt wird.

Jedoch hat das Singleton Design Pattern einige grundlegende Probleme. Das ist nicht neu und wird unter Entwicklern bereits seit mehreren Jahren diskutiert (einfach nach “evil singleton” suchen http://www.google.de/search?hl=de&q=evil+singleton). Das Singleton verletzt mehrere Regeln eines guten objektorientierten Designs. Code welcher die Singleton-Klasse benutzt hängt von dieser ab, er ist nicht ohne sie nutzbar, was ihn dazu auch noch schwer zu testen macht. Der Code ist dann nicht gegen ein Interface programmiert, sondern gegen eine konkrete Klasse, und daher fest an das Singleton gekoppelt, anstatt einer gewünschten losen Kopplung zwischen beiden Klassen. Darüber hinaus sind Klassen, die das Singleton Pattern implementieren selbst schwer zu testen. Singletons ersetzen globale Variablen und verstecken sie in einer Klasse – der globale Zustand bleibt in der Anwendung. Wenn allgemein die Ansicht herscht, dass ein globaler Zustand schlecht ist und das sein Auftauchen als Singleton den Code nicht besser macht, warum wird das Singleton Design Pattern dann so oft benutzt?

Um diese Frage zu beantworten möchte ich zunächst einen Schritt zurückgehen und einmal eine Klasse beleuchten, die als Singleton implementiert ist. Wenn man sich eine typische Implementierung anschaut, dann kann man die Methoden in solchen Klassen in zwei Kategorien einteilen: solche die für die Geschäftslogik zuständig sind und solche, die für das Erzeugen und den Zugriff auf die Instanz zuständig sind. Wie man sieht sind dies zwei verschiedene Verantwortlichkeiten. Bei guter Objektorientierung sollte eine Klasse nur eine Verantwortlichkeit haben, aber trotzdem benutzen wir ein Design Pattern das zwei verschiedene Verantwortlichkeiten in einer Klasse vermischt. Warum sollte eine Klasse entscheiden wie viel Instanzen von ihr in einer Anwendung erzeugt werden dürfen? Eigentlich sollte sie gar nicht wissen wie viel Instanzen von ihr herumfliegen, es ist einfach nicht ihre Aufgabe. Es sollte einfach nur die Geschäftslogik in sich bestmöglich ausführen, und aus meiner Sicht hat sie damit alle Hände voll zu tun.

Andererseits ist es vollkommen ok die Anzahl der Instanzen einer Klasse zu beschränken. Und natürlich möchten wir andere Programmierer davor bewahren, die Beschränkungen unseres Codes zu umgehen. Dennoch, warum sollte sich ein anderer Programmierer darum Gedanken machten, wie viel Instanzen einer bestimmten Klasse in einer Anwendung erlaubt sind (abgesehen von Performance-Gründen)? Der andere Programmierer sollte in seinem Code einfach sagen “Ich benötige eine Instanz von Logger, und mein Code wird nicht ohne arbeiten, und zum Teufel noch mal ist es mir egal wie viel Instanzen von Logger erlaubt sind, gib mir einfach irgendeine!”.

Zurück zu den Verantwortlichkeiten einer Klasse: eine Klasse ist für die in ihr enthaltende Geschäftslogik verantwortlich, und es ist dafür verantwortlich die Abhängigkeiten zu definieren, um die Geschäftslogik korrekt ausführen zu können. Durch die Nutzung einer Singleton-Klasse wird diese Abhängigkeit innerhalb der Klasse versteckt. Es ist nicht möglich, aus der API heraus zu erkennen, dass die Klasse von einer anderen abhängt, sofern es nicht entsprechend dokumentiert ist. Darüber hinaus sollte eine Klasse sich nicht darum kümmern müssen wie Klassen erzeugt werden von denen sie abhängt. Zusammengefasst: eine Klasse sollte ihre Abhängigkeiten explizit deklarieren, und dies erfolgt durch die Definition eines Konstruktors, der sagt “Ich benötige dieses und jenes um korrekt zu arbeiten, und wenn Du mir das nicht gibst bekommst Du auch keine Instanz von mir”. Ein wenig Code um das darzustellen:

Schlecht:

class Foo {
  protected $logger;
  public function __construct() {
    $this->logger = Logger::getInstance();
  }
...
}

Gut:

class Foo {
  protected $logger;
  public function __construct(Logger $logger) {
    $this->logger = $logger;
  }
...
}

Das zweite Beispiel sagt deutlich, dass Foo eine Instanz von Logger benötigt um erzeugt zu werden. Gute Doc Comments vorausgesetzt (im Beispiel weggelassen um es kurz zu halten) wird die generierte API-Dokumentation dem Benutzer von Foo sagen dass man einen Logger benötigt um ein Foo zu erzeugen. Zusätzlich ist Foo sehr viel einfacher zu testen, da man statt einer konkreten Klasse auch ein Mock-Objekt injizieren könnte. Natürlich gibt es für diese Art der Programmierung auch einen Namen: Dependency Injection. Die kürzeste Erklärung dafür könnte wie folgt lauten: “Dependency Injection bedeutet dass eine Klasse ihre Abhängigkeiten als Parameter im Konstruktor oder via Setter-Methoden injiziert bekommt”.

Wenn man dem Dependency Injection-Prinzip folgt kann man seine Klassen in zwei Kategorien einteilen: solche die nur die Geschäftslogik beinhalten, und solche die dafür zuständig sind Instanzen anderer Klassen zu erzeugen und diese zusammen zu fügen.* (Das hatten wir doch schon mal weiter oben, oder?) Das gute daran ist, dass wir die Klassen der Geschäftslogik auch anders zusammensetzrn könnten und ein anderes Verhalten erhalten würden – ohne die Klassen der Geschäftslogik überhaupt anpassen oder ändern zu müssen.

Aber wie stellen wir jetzt sicher, dass es nur eine Instanz von einer bestimmten Klasse gibt? Das liegt einfach in der Verantwortung der Klasse, die für die Erzeugung von Instanzen zuständig sind. Dort kann man eine Logger-Instanz erzeugen und wo immer eine Klasse einen Logger benötigt übergibt man genau diese Instanz. Damit erhält man ebenfalls ein singleton*, aber ohne den Nachteil der mit dem Singleton Design Pattern einhergeht. Ein zusätzlicher Vorteil: sofern man auf einmal feststellt dass man mehr als eine Instanz von Logger benötigt muss man den Logger selbst nicht ändern, und auch nicht den Code der Logger benutzt. Man muss ausschließlich den Code zum Erzeugen und Zusammenfügen von Objekten anpassen.

Zugegebenermaßen erzeugt dieser Weg sehr viel Boilerplate-Code (der zum Erzeugen und Zusammenfügen der Objekte). Solchen Boilerplate-Code zu schreiben ist wirklich langweilig, wird schnell lästig und macht keinen Spaß. Hier kann ein Dependency Injection-Framework helfen. Aber das ist eine Geschichte für einen anderen Tag.

Ein letzter Punkt: Entwickler, die an das Thema Dependency Injection herangeführt werden sind oftmals von der Idee selbst fasziniert, stellen aber meist die gleiche Frage: Muss ich alle in einer tieferen Schicht benötigten Instanzen bereits an die darüber liegende Schicht übergeben, damit diese sie an die darunterliegende Schicht weitergeben kann? Die kurze Antwort: nein. Zumindest nicht wenn man es korrekt implementiert. Ein Beispiel: Ein Haus hat eine Tür, und die Tür hat ein Schloss. Wenn das Haus ein Schloss benötigt um es an die Tür zu übergeben ist das Design falsch. Das Haus sollte nur eine Tür benötigen. Ob die Tür ein Schloss benötigt oder nicht ist völlig unwichtig für das Haus. Eine Implementierung könnte dann so aussehen:

class House {
  protected $door;
  public function __construct(Door $door) {
    $this->door = $door;
  }
  ...
}

class Door {
  protected $lock;
  public function __construct(Lock $lock) {
    $this->lock = $lock;
  }
  ...
}

Das Haus muss nichts über Schlösser wissen – nur über Türen. Selbst wenn es irgendwas mit Schlössern tut sollte dies über Methoden der Door-Klasse erfolgen. (Eigentlich sollte Door ein Interface sein, aber für diese kurze Beispiel ist es ok, wenn Door eine Klasse ist.)

Um die Frage von oben zu beantworten: Das Singleton Design Pattern wird so oft genutzt weil der Rest des Codes Lücken im Design hat, wenn die Geschäftslogik und die Erzeugungslogik nicht korrekt verteilt sind. Es ist kein Problem die Anzahl der Instanzen einer Klasse zu limitieren, aber um das richtig mit einer einzelnen Instanz in der Erzeugungslogik zu tun muss der Rest der Anwendung mit Dependency Injection im Hinterkopf designt werden. Man könnte meinen, dass Code refactored werden muss solange es Spuren von Singletons enthät.

* Eine Ausnahme davon sind Klassen die nur Werte und Daten aber keine Logik enthalten – diese können durchaus von den Klassen der Geschäftslogik durch die Nutzung eines anderen Erzeugungsmusters erzeugt werden.

** Man könnte es “das kleine singleton” nennen – mit einem kleinen s im Gegensatz zum Design Pattern, das mit einem großen S beginnt.

Anschließend teilte sich die Veranstaltung in zwei Tracks auf. Im ersten Track ging es um Ajax mit PHP, was auch die Mehrzahl der Zuhörer fand, während im zweiten Track Martin Aschoff über die Entwicklung und Vermarktung von Open-Source-Applikationen sprach. Das hinter einem erfolgreichen Open-Source-Projekt weitaus mehr steckt als einfach nur irgendwo etwas zum Download anzubieten machte dieser Vortrag mehr als deutlich, vor allem wenn es darum geht ein Geschäftsmodell rund um die veröffentlichte Software aufzubauen. Aus Unternehmenssicht muss so etwas ebenso einen Business Case haben wie ein ganz normales neues Produkt, und das “Drumherum” muss ebenfalls professionell sein: Dokumentation, Bug Tracker, Roadmap und Einstellen der Applikation bei SourceForge sind dabei nur einige offensichtliche Punkte der viel größeren Liste zu beachtender Punkte.

Nach der Mittagspause ging es in Track 1 weiter mit dem Test von PHP-Webanwendungen, dass ebenfalls großes Interesse fand. Wesentlich weniger Zuhörer fanden sich dagegen in der Veranstaltung von Track 2 ein, wo Piere Joye über PHP auf Windows sprach. Ich fand das geringe Interesse sehr erstaunlich, wo doch weit über die Hälfte aller PHP-Entwickler unter Windows arbeitet. Zunächst gab es einen schonungslosen Blick auf den aktuellen Zustand von PHP 5.2 unter Windows – zusammengefasst kann man nur sagen: es ist katastrophal. Bis Januar 2008 nur ein Entwickler, der sich um das Thema gekümmert hat, bis zu 10 Jahre alte verwendete Bibliotheken, ein 11 Jahre alter Compiler und das Interesse der PHP-Core-Entwickler an der Lauffähigkeit unter Windows nahezu null – Hauptsache es kompiliert. Ein produktiver Einsatz von 5.2 unter Windows sei auf gar keinen Fall zu empfehlen, so Piere Joye.

Das ändert sich glücklicherweise alles mit PHP 5.3, auch dank des Engagements von Microsoft. Das Team umfasst mittlerweile 10 Leute, in den letzten Monaten wurden alle verwendeten Bibliotheken auf den neuesten Stand gebracht, es kann nun mit einem aktuellen Compiler gebaut werden (allein das brachte mit dem üblichen PHP-Benchmark einen Performance-Gewinn von etwa 20%), und ein Windows-only-Bug in einem Release Candidate ist ab sofort im Gegensatz zu bislang ein Show-Stopper. Die Frage, warum Microsoft das tut, beantwortete Piere Joye mit einem einzigen Stichwort: Interoperabilität. Das ist es, was Kunden heutzutage fordern und dem sich auch Microsoft zu stellen hat.

Als letzten Vortrag gab es im Track 1 etwas zum Thema PHP Design Patterns, während im Track 2 ein Ausblick auf PHP 6 gegeben wurde. Da ich den ersteren Vortrag hielt blieb mir hier keine Wahl, und so habe ich kurz die Regeln für gutes Software-Design vorgestellt, kurz erläutert was Design Patterns eigentlich sind, um dann gleich ins Thema zu gehen und vom Einsatz des Singleton abzuraten, weil es ein schlechtes Pattern ist. Mehr dazu vielleicht in einem späteren Artikel. Neben kurz vorgestellten Beispielen aus der Gruppe der Erzeugungsmuster, Strukturmuster und Verhaltensmuster ging ich dann noch auf das Thema Dependency Injection ein, das bei diesem Thema nicht mehr wegzudenken ist. Natürlich konnte ich vieles auf Grund der Zeitbegrenzung nur anreißen – dem interessierten Zuhörer bleibt nicht erspart, sich selbst weiter zu informieren.

Als Abschluss sollte es noch eine Diskussion zur Zukunft von PHP geben – ob diese stattgefunden hat kann ich allerdings nicht mehr sagen, da ich bereits abreisen musste. Vielleicht liest ein Teilnehmer mit und kann dazu noch kurz etwas in den Kommentaren schreiben.

Als erstes gab Martin Goldmann eine Einführung in das Thema Frameworks. Was sind Frameworks, was ist ihr Nutzen und wo liegen die Knackpunkte beim Einsatz eines Frameworks waren die behandelten Fragen. Der Vortrag entwickelte sich recht schnell in eine Diskussion über einzelne Punkte, beispielsweise zum Thema Sicherheit in Open Source Frameworks. Für diejenigen, die sich erst noch für ein Framework entscheiden müssen wurden einige Fragen vorgestellt, die man sich vor der Entscheidung oder im Rahmen einer Evaluation beantworten sollte. Knackpunkte dabei sind Fragen wie stark der Community-Support für ein Framework ist, zum Dokumenationsumfang des Frameworks, Lizenzfragen und natürlich generell zum Einsatzziel selbst. Insgesamt eine gute Einführung in das Thema, so dass man als Teilnehmer gut vorbereitet in die Workshops zu den drei vorgestellten Frameworks (oder Klassenbibliotheken) eZ Components , Zend Framework und FLOW3 gehen konnte. Wer noch mehr Frameworks kennenlernen möchte sei auf http://www.phpframeworks.com verwiesen.

Den Anfang der einzelnen Workshops machte Tobias Schlitt mit einem Einblick in die Welt der eZ Components. Als Mitentwickler der eZ Components mit sehr fundiertem Wissen entwickelte sich der Vortrag zunächst in eine recht werbelastige Richtung. Nach dem Werbeblock mit viel Hintergrund rund um die ez Components wurde dann ein Überblick über die verfügbaren Komponenten gegeben, bei der jeder größere Komponentenblock kurz angesprochen wurde. Anschließend ging es dann in die Details mit der Vorstellung von Basiskonzepten wie den Komponentenbeziehungen (Tie-ins), Structs und Options. Alles in allem ein fundierter Überblick über die eZ Components, der mit einem mehrheitlich von den Zuhörern gewünschten tieferen Einblick in die Datenbank-Komponenten endete.

Nach der Mittagspause war das Zend Framework an der Reihe, vorgestellt von Jan Burkl, seines Zeichens Training & System Engineer bei Zend. Zunächst gab es jedoch einen Einblick in PDT und Zend Studio for PHP und deren Features. Nach diesem kleinen Werbeblock stand eine Übersicht über die vorhandenen Bestandteile des Zend Frameworks auf der Tagesordnung, gefolgt von einem detaillierten Blick auf die Komponenten und ihre Bestandteile. Da alle Theorie grau ist gab es dann eine Demo, bei der Jan Burkl sowohl die Arbeit im Zend Studio for PHP als auch mit Zend Framework live demonstrierte. Einer kurzen Erläuterung der Struktur und des obligatorischen Hello World-Beispiels folgend wurde gezeigt, wie mit dem Zend Framework ein Login gebaut werden kann, bis hin zur Integration mit Dojo.

Als letztes präsentierte Tobias Hauser das noch in Entwicklung befindliche FLOW3, welches als Framework die Grundlage für das geplante TYPO3 5.0 bildet. Da FLOW3 bedeutend weiter geht als viele andere erhältliche PHP-Frameworks bezog sich ein großer Teil des Vortrags auf die Erklärung der Hintergedanken und Konzepte zu FLOW3 wie beispielsweise Domain Driven Development oder Aspect Oriented Programming. Dies ist dem Umstand geschuldet, dass es derzeit leider nicht allzuviel zu zeigen gibt, da vieles Work in Progress ist. Mit einem ersten Alpha-Release ist wohl auch frühestens in einigen Monaten zu rechnen, wobei das laut Aussage von Tobias Hauser eine optimistische Annahme sei.

Morgen gibt es dann den zweiten Tag mit insgesamt 6 Vorträgen und einer Keynote, wobei immer zwei Vorträge parallel stattfinden. Über alles werde ich daher nicht berichten können, zumal ich ja auch meinen eigenen Vortrag halten muss.