An anderer Stelle hatte ich ja bereits ein paar Gedanken zu PHP-(micro-)Frameworks und Ed Finklers microPHP-Manifest notiert. Meine erste Sympathie für diverse Ansätze und Frameworks wie Epiphany war schnell einer gewissen Ernüchterung gewichen. Zu viel machen die von mir angeschauten Frameworks auf eine Art, die ich für meine Arbeit nicht übernehmen will oder kann. Aber ich bin vom Ansatz des micro-Frameworks immer noch überzeugt. Nicht als generellen Ersatz für größere Frameworks — auch die haben weiterhin ihre Berechtigung —, sondern als Alternative für Projekte, bei denen es passt. Wie aber wünsche ich mir die Alternative?
Was mir aber schnell aufgefallen war, war die schlichte Tatsache, dass ich zwar wusste, was ich nicht wollte, aber nicht formulieren konnte, wie denn ein Framework nach meinen Vorstellungen aussehen sollte. Das will ich hier nachholen. Dass es genau zehn Punkte geworden sind, ist reiner Zufall. Ich will mit dieser schönen Zahl deshalb auch nichts aussagen; es kann durchaus noch weitere gute Kriterien geben und ich will hier keine Framework-Manifest oder sowas schreiben. Die Liste ist vorerst nicht mehr, als ein Haufen Notizen.
Eigentlich läuft das ganze darauf hinaus, drei Aspekte zu berücksichtigen: Größe, Flexibilität und Offenheit: Das Framework muss klein sein, dem Entwickler möglichst wenig Vorgaben machen und darf Erweiterungen nicht im Wege stehen.
1. Einfachst! Kleinst!
Das versteht sich bei einem micro-Framework eigentlich von selbst. Das Grundproblem lösen und lieber mal was weglassen. Sich an Apples Design orientieren: Einstellbar machen, was einstellbar sein muss, der Rest geht auch mit den Standard-Settings.
Wenn man doch etwas anders benötigt, als es das Framework vorsieht, sollte man es durch Erweiterungen lösen können (s.unten).
Was gleich zum nächsten Punkt überleitet:
2. Minimalinvasiv
Darunter fallen gleich mehrere Punkte, aber es ist auch besonders wichtig:
2.1 Keine Vorschriften zu Benennung von Projekt-Verzeichnissen, keine vorgegebene Projekt-Struktur
Das Framework sollte mich meine Arbeit so organisieren lassen, wie ich es will. Klar ist auch eine vorgegebene Verzeichnis-Struktur eine Arbeitserleichterung, vor allem, wenn man sich in fremdem Code zurecht finden muss; aber eine solche Vorgabe kann man ja immer noch einführen, man muss das nicht auf Framework-Ebene abhandeln. Best practices sind ok, aber best darf nicht zum must werden.
2.2 Einfache Objekte, keine Notwendigkeit Framework-spezifischer Parent-Klassen
Wo immer man Anwendungs-Code schreibt, sollte dieser Code völlig unabhängig vom verwendeten Framework sein. Ich will keine Framework-Klassen in der Anwendung, sondern das, was man in Java POJO – Plain Old Java Objects nennt.
3. Unabhängigkeit der Komponenten nach Innen und nach Außen
Nur durch die Unabhängigkeit voneinander kann ich mich auf das beschränken, was ich brauche, und nur durch Unabhängigkeit der Komponenten untereinander sind sie flexibel austauschbar. Abhängigkeiten zu externen Libraries etc. können problematisch werden, wenn Framework und Anwendung die gleichen Libraries benötigen, aber z.B. in verschiedenen Versionen.
4. Objektorientiert, Namespaces
Ersteres ist durchaus nicht selbstverständlich, in PHP ohnehin nicht. In seiner Replik auf das microManifesto fordert Kris Jordan, Funktionen als die kleinste Einheit zu sehen; kann er ja machen, aber ich will ein objektorientiertes Framework — und zwar richtig, d.h. mit Namespaces, Klassen und Objekten.
5. Keine globalen Variablen, dass Framework soll nichts in den globalen Namespace einführen
Eigentlich klar, aber als Kriterium trotzdem wichtig.
6. Auf bekannten Patterns basierend
Klingt nach Geschmackssache, ist aber mehr. Denn Patterns sind bewährte Lösungswege, über die ich mich auch noch an anderer Stelle informieren kann, wenn der Groschen nicht gleich fallen will.
7. PHP als nicht-typisierte Sprache nutzen – strong typing ist gut, manchmal aber auch im Weg
Warum nicht ein Feature von PHP nutzen, wenn es manchmal einfach gut passt? Ein Framework sollte die zugrunde liegende Sprache nutzen, ihre Features nicht ausblenden.
8. Arbeitserleichterung
Das Framework sollte Klassen enthalten, die flexibel zur Arbeitserleichterung eingesetzt werden können (aber nicht müssen). Das Paradebeispiel dafür sind Libraries zum einfacheren Umgang mit Datenbanken. Natürlich wird Anwendungs-Code, der solche Hilfsklassen einsetzt, abhängig vom Framework; wenn aber das Kriterium der Unabhängigkeit der Framework-Klassen untereinander erfüllt ist, kann man damit leben, weil es nur dort hilft, wo es eingesetzt wird, aber woanders nicht stört.
9. Offenheit für individuelle Erweiterungen, Anpassungen
Wenn ein Framework klein ist, wird es Fälle geben, wo es nicht out of the box passt. Hier müssen Anpassungen und Erweiterungen möglich sein, sonst ist das Framework nicht universell genug.
(10. Dependency Injection, Inversion of Control)
Dieser Punkt steht in Klammern, weil er viel weniger zwingend ist als die anderen neun Punkte und die anderen Aspekte nur im Hinblick ihrer Realisierbarkeit zusammenfasst. Wie die genannten Punkte umgesetzt werden, soll ja offen bleiben. Aber: Inversion of Control und Dependency Injection sind bewährte Patterns, mit denen sich alle Punkte umsetzen lassen. Es liegt nahe, sie dann auch einzusetzen.