In den kommenden Wochen werde ich Zeitgeist einer handvoll befreundeter Entwickler zugänglich machen, auf dass diese es auseinander nehmen können und mir möglichst schonungslos alle Designfehler und kleinen Faulheiten unter die Nase reiben. Dabei geht es darum zum ersten Mal das Framework wirklich in seiner Gänze an Dritte zu geben, damit diese es benutzen bzw. durchtesten können.

Interesse?

Wenn du jetzt gerade aufgehorcht und schon überlegt hast mit wem du ins Bett gehen musst, um ebenfalls an das Framework heranzukommen – keine Sorge: eine Mail genügt. Es muss nur die richtige Mail sein. Genauer gesagt musst du selbst einige Voraussetzungen erfüllen.

Zeitgeist ist ein PHP5 basiertes Framework, was ordentlich Gebrauch von OOP macht. Dazu kommt, dass ZG kein WYSIWYG Framework ist, das euch an die Hand nimmt, sondern nur ein ziemlich dünner Unterbau, der einem zwar viele Freiheiten lässt, aber auch viel abverlangt. Kurz: du solltest kein Einsteiger in Sachen Webentwicklung sein. Am besten hast du schon ein paar eigene, kleinere Projekte erfolgreich umgesetzt. Und damit meine ich nicht “phpBB installiert”, sondern eigene Applikationen und Plattformen entwickelt.

Ideal wäre es natürlich, wenn ihr gerade mit der Entwicklung eines kleinen Projekts beginnen wollt und genug Gottvertrauen habt, um auf ein völlig fremdes Framework zu setzen.

Was habt ihr davon Zeitgeist zu nutzen?

Mit einem Wort: Unterstützung. Ich rede nicht von First-Level-Support oder Hotlines, sondern davon, dass ich euch zuhören werde, jede Anregung beachte und zumindest überdenke, gerne zu konstruktiven Diskussionen bereit bin und natürlich euch bei Fragen zum Einsatz des Frameworks unterstützen will.

Dazu kommt, dass Zeitgeist selbst mitnichten ungetestete Alpha-Software ist. Das Framework wurde als Ganzes und in Teilen erfolgreich in mehreren kleinen und mittleren Projekten getestet. Natürlich kann und wird sich noch einiges am Framework verändern, jedoch ist es in jeder Hinsicht für den produktiven Einsatz verwendbar.

Die Zukunft von Zeitgeist

Zeitgeist wird mittelfristig Open Source werden und für alle zugänglich gemacht. Der Zeitplan sieht vor, dass dies allerdings noch bis mindestens 2010 dauert, also haltet nicht den Atem an. Der Plan sieht vor die Ergebnisse dieser geschlossenen Feedback-Runde einzuarbeiten und die Dokumentation weiter auszubauen. Dazu kommt eine Art FAQ und First-Steps-Dokument, um einsteigende Entwickler zu unterstützen. Das wird jedoch noch einige Zeit in Anspruch nehmen. Bis dahin bleibt es spannend.

Oh, und wie schon getwittert ist mir etwas tolles passiert. Das nervigste daran ist eindeutig nicht darüber reden zu dürfen. Narf! Wenn ihr trotzdem wissen wollt, wie es in Metaplace aussieht, registriert euch schnell.

Die Frage war:

Was ist dieses angesprochene Message-System?

Nun, einfach gesagt: Die Message-Klasse stellt Funktionalitäten bereit, um systemweite Textnachrichten zu verwalten.

Das Prinzip der systemweiten Nachrichten sollte vielen bekannt sein, die schon einmal etwas tiefer in die  Dektop-Programmierung eingestiegen sind. Man kann es sich als eine Art Modul vorstellen, das von überall her angesprochen werden kann. An dieses Modul können Nachrichten übergeben und umgekehrt wieder angefordert werden. Auf diese Weise können alle Module eines Projekts miteinander kommunizieren.

Ein Beispiel

Nehmen wir einmal einen typischen Fall in einer Webapplikation: ein Benutzer kauft in einem B2B-Webshop den Inhalt seines Warenkorbs. Dieser einfache Klick setzt einige Abläufe in Gang – gehen wir der Einfachheit mal von folgenden Prozessen und Fragen aus, die das System nun anstößt:

• Ist der Benutzer eingeloggt?
• Kenne ich alle nötigen Angaben des Benutzers?
• Was ist denn der Inhalt des Warenkorbs
• Sind die Waren überhaupt noch verfügbar?
• Erstelle eine Rechnung
• Informiere das Warenwirtschaftssystem

Diese können leicht durch Klassen und deren Methoden beantwortet werden. Allerdings werden dabei viele, viele Zwischenfragen gestellt und lauter Klassen müssen ineinander greifen: Benutzerverwaltung, Warenkorb, Waren, Rechnungsstellung, Schnittstelle zum Warenwirtschaftssystem und so weiter. Der ganze Ablauf wird wahrscheinlich verwaltet durch eine Art Controller (in MVC), mit dem jede Klasse für sich sprechen kann. Doch wie können diese individuellen Klassen miteinander sprechen?

Falsch!

Einfache Antwort: in sauberem OOP sollen Arbeiterklassen auch gar nicht untereinander Daten austauschen. Gut, zugegeben. Aber abgesehen von Daten: wie wäre es, wenn sie Informationen über ihren Zustand austauschen? Oder sie alle wollen möglicherweise mit dem Controller oder gar dem Benutzer reden. Und dieses Mitteilungsbedürfnis kann eben über den einfachen Rückgabewert hinaus gehen. Wenn mir eine Methode einer Arbeiterklasse ein false zurückliefert, was ist denn eigentlich genau schief gelaufen? In welchem Zustand befindet sich dann die Arbeiterklasse? (An dieser Stelle würde ich ja gerne mit Exception Handling anfangen, aber die Implementation in PHP5 ist so mangelhaft, dass das leider nicht geht).

Also – gehen wir von einer Art Verbose-Modus innerhalb der Applikation aus, in dem jede Klasse ihre Schritte dokumentieren kann und alle anderen wissen, in welchem State sich die Applikation gerade befindet.

Die Umsetzung

Gundsätzlich könnte man jetzt das Problem mit globalen Variablen lösen. Mal abgesehen von dem “globale Variablen sind die Wurzel allen Übels”-Stigma sind sie wirklich nicht besonders sinnvoll. Es ist schwer im Blick zu halten, welche Funktion gerade was in welche Globale geschrieben hat, was Debugging und vor allem Testing zu einem Horrortrip macht.

Alternativ würden sich Session-Variablen anbieten, aber wenn man es genau betrachtet sind diese in dem Zusammenhang auch nichts anderes als Globale in Grün.

Was ist daran schlecht?

Das da:

Warum machst du es dann doch, obwohl sogar Google sagt, dass es schlecht ist?

Wer aufgepasst hat, der hat sich gemerkt, dass Singletons (über die wir hier reden) nicht per se schlecht sind. Man muss sie nur entsprechend designen. Denn grundsätzlich haben Singletons einige entscheidende Vorteile gegenüber einer Anzahl von “dummen” Globalen.

Zunächst einmal wäre da die Nachvollziehbarkeit. Die Klasse selbst kann nachvollziehen welche Methode oder Funktion gerade auf sie zugegreift und was diese verändert. Voraussetzung ist, diese Informationen fließen alle in eine Art Tracing-Mechanismus, was dem Entwickler zu jeder Zeit des Programms transparent macht, was an welcher Stelle passiert ist. In der Kombination mit dem Tracer bleibt dann nachvollziehbar, was genau mit dem Global State passiert (siehe Video).

Ich erwähnte bereits, dass das Nachrichtensystem die Informationen nicht nur speichert, sondern auch verwaltet. Eine Methode kann eine Nachricht mit einem expliziten Empfänger versehen. Somit erhält eine Methode an anderer Stelle bei einer Anfrage nach für sie relevanten Nachrichten auch nur die für sie gespeicherten Informationen.

Möglich ist auch eine effektive Rechteverwaltung, welche Module auf welche gespeicherten Informationen zugreifen bzw. diese verändern können.

Und schließlich: Nachrichten können über Aufrufe hinweg gespeichert werden. Ein Beispiel: wenn bei einem Aufruf einige Funktionen einen Fehler melden, der Benutzer daraufhin per Redirect auf eine andere Seite geleitet wird, kann das System immer noch nachvollziehen, welche Fehler eigentlich gemeldet wurden und dem Benutzer entsprechende Ausgaben präsentieren. Das ist eigentlich die Hölle für einen Global State, aber noch einmal: wir können leicht nachvollziehen wer den State wann gesetzt hat. Und umgekehrt können wir diesen auch leicht definieren, um ihn so testen zu können.

Fazit

Ja, das ist Overhead. Aber nicht so viel, wie man denkt. Macht es das Debuggen und Warten des Codes problematischer? Ja, ein bischen. Oder vielmehr: man sollte sich über ein paar Dinge im Klaren sein. Dann aber ist es immer nett, wenn man mehr Informationen zur Verfügung hat, was genau in der Applikation vorgeht – auch innerhalb der Applikation selbst.

Aber um eine Sache klarzustellen: wir reden hier von Nachrichten, Kommunikation und Übersicht. Die eigentilchen Arbeiterklassen sollten entsprechend korrektem OOP-Design erstellt werden (siehe oben, siehe Vortrag). Was nicht Sinn der Sache ist, dass (wie in unserem B2B-Shop-Beispiel) der Warenkorb plötzlich über das Nachrichtensystem von einer Arbeiterklasse zur nächsten gereicht wird. Dann sind wir in der Tat bei “Bad Global State”.

Wie bereits erwähnt hat Zeitgeist eine recht komplexe Nutzerverwaltung. Ein Benutzer hat Kerndaten, zum Beispiel Nutzername, Passwort und diverse Schlüssel. Dazu kommen weitere, applikationsabhängige Nutzerdaten, zum Beispiel Vorname, Nachname, Adresse usw. Normalerweise handelt es sich hierbei um 1:1 Beziehungen. Die Daten sind dennoch in eine extra Tabelle ausgelagert und besitzen eine eigene Verwaltung. Der Grund ist, dass man so von Applikation zu Applikation die Nutzerdaten leicht erweitern kann, oder (Beispielsweise bei Webshops mit mehreren Lieferadressen) einfach 1:n Beziehungen abgebildet werden können.

Darüber hinaus hat jeder Benutzer eine Anzahl von Rechten. Rechte sind Beschränkungen bzw. Freigaben von Aktionen der Applikation. Und schließlich hat ein Benutzer eine oder mehrere Rollen: Sammlungen von Rechten.

Unsere Hauptdarsteller sind also: Nutzerverwaltung (der ganze administrative Kram, einschließlich Login, Sicherheit, Nutzervariablen  etc.), Nutzerdaten, Nutzerrechte und Nutzerrollen.

Bei der Implementation begannen  die Probleme.

Iteration 1: Die Superklasse

Zunächst hatte ich alle Funktionalität in einer Klasse, die alle Aspekte der Benutzerverwaltung vereinigte. Schritt für Schritt aufgebaut wuchs sie langsam, aber stetig. Ich persönlich hasse es, wenn Klassen über eine bestimmte Größe hinauswachsen. Also war der logische Weg: die Klassen aufspalten. Aber wie?

Iteration 2: Aufteilen in einzelne Dateien

Da im Prinzip alle Komponenten zusammenarbeiten, wollte ich eigentlich alles in einer Klasse belassen. Mein erster Gedanke war also die Klasse einfach nur auf einzelne Dateien aufzuteilen und per Include zusammenzufassen.

Schnell zeigte sich: PHP kann zwar Inhalte von Methoden per Include aus externen Dateien einbinden, aber keine Methoden einer Klasse. Klingt zunächst mal komisch, nachdem ich die Kommentare der PHP-Entwickler zu dem Thema gelesen hatte, war mir aber einiges klar. Na gut, also anders.

Iteration 3: Ableitungen und Zuflüsse

Im Grunde ist das Szenario eines der wenigen sinnvollen Anwendungen für Multiple Inheritance, auch bekannt als Mehrfachvererbung. Im Grunde könnte ich die Nutzerdaten, Nutzerrecht und –Rollen einfach in einzelne Klassen packen und eine Benutzer-Klasse darüber von allen drei erben lassen. Doch, richtig, PHP kann keine Mehrfachvererbung.

Dem Vorschlag in einem Forum doch lieber Chain Inheritance zu nehmen, habe ich gleich den Vogel gezeigt. Auch Interfaces, die immerhin mehrfach geerbt werden dürfen, bringen mir hier gar nichts.

Iteration 4: Die Rückkehr der Superklasse

Also blieb es bei der Superklasse. Sie funktionierte tadellos und so lange ich keinen Blick in die Datei warf, war alles gut – Bis mir die Situation bei dem letzten Refakturierungslauf endgültig auf die Nerven ging. Ja, wir reden hier von einem ästhetischen Problem, aber das ist wohl bezeichnend für den Stil von Zeitgeist: Funktionalität und Lesbarkeit gehen Hand in Hand.

Iteration 5: Die Worker-Konstruktion

Also gut. Nutzerdaten, Nutzerrechte und –Rollen sind eigene Klassen. In diesen Klassen ist die jeweilige Logik der Komponenten untergebracht. Die Klassen werden von der Benutzerklasse ganz normal instanziert. Für die Kommunikation der Klassen untereinander sorgt ebenfalls die Benutzerklasse.

Es liegt eigentlich nahe die einzelnen Bereiche einfach in eigene Klassen auszulagern, in so fern frage ich mich, wieso ich es nicht die ganze Zeit so gemacht hatte. Auf der anderen Seite erfordert das Zusammenspiel der Klassen einiges an Overhead, was sich nur durch eine recht clevere Einbindung vermeiden lies: die Klassen werden nur geladen, wenn sie gebraucht werden. Wenn die Nutzerdaten nicht gebraucht werden, wird auch nichts geladen – weder die Klasse, noch die Daten aus der Datenbank.

Dazu kommt noch, dass sich die kleinen, abgeschlossenen Klassen wesentlich besser von den Unit Tests testen lassen.

Fazit

Wieso nicht gleich so? – Weil‘s Aufwand war.
Hat es sich gelohnt? – Auf jeden Fall.
Wird’s dabei bleiben? – Ich hoffe doch! Jetzt habe ich keine Lust mehr, das Ding anzufassen