Aura zerschlägt den Solar-Monolithen – Interview mit Paul M. Jones
Kommentare

Paul M. Jones hat unlängst die General Availability der meisten Komponenten seines Aura Frameworks angekündigt. Es handelt sich um das erste Framework, was komplett auf PHP 5.4 basiert. Schon mit dem

Paul M. Jones hat unlängst die General Availability der meisten Komponenten seines Aura Frameworks angekündigt. Es handelt sich um das erste Framework, was komplett auf PHP 5.4 basiert. Schon mit dem Vorgänger SolarPHP wagte Jones als erster den großen Schritt in eine neue PHP-Version, damals war es PHP 5. Im Interview klärten wir mit ihm so manche Warum-Frage.

PHP Magazin: Hallo Paul. Erst einmal Glückwunsch zum Release der 1.0 von Aura.

Paul M. Jones: Danke! Die meisten Pakete sind 1.0, aber drei sind noch in der Beta. Diese sollten aber auch bald „stable“ sein.

PM: Warum hast du’s gemacht?

Jones: Aura ist im Grunde die zweite große Version des Solar Frameworks. (Solar war das erste E_STRICT-Framework für PHP 5; es wurde noch vor dem Zend Framework entwickelt.) Eine von Anwendern häufig gestellte Frage bei Solar war „Ich will nur einen Teil von Solar verwenden. Kann ich das tun, ohne das komplette Framework herunterladen und konfigurieren zu müssen?“ Die Antwort war natürlich „Nicht wirklich.“ Es war ein monolithisches Framework, wo alle Teile so designt waren, dass sie in relativ starker Abhängigkeit zueinander arbeiten.

Mit Aura haben wir also von einer anderen Richtung her begonnen. Wir wollten, dass die Teile einzeln verwendbar sind, ohne jegliche Abhängigkeiten. Erst hinterher würden wir aus den Stücken ein Framework bauen. Wir nannten das unser „Bibliotheken zuerst, Framework danach“-Prinzip. Das bedeutet, du kannst nur ein einziges Aura-Paket verwenden, wenn du möchtest, und du wirst nicht von vielen anderen Paketen abhängig werden; jedes ist selbstgenügsam, selbst in Sachen Tests. Jedes nutzt separate Schnittstellen, um Datenobjekte zu übertragen, mit denen Informationen über Paketgrenzen hinweg ausgetauscht werden.

Zusätzlich wollten wir aus allen Lektionen aus Solar lernen, die Abwärtskompatibilität komplett über Bord werfen, und ganz von vorne beginnen. Der größte BC-Break ist, dass wir diesmal auf eine Service-Locator-Implementierung oder einen universellen Konstruktor verzichtet haben und stattdessen auf ein DI-orientiertes System umgestellt haben. Diese eine Änderung hat für gigantische Verbesserungen gesorgt in Sachen Entkopplung, Testierbarkeit und Paket-Unabhängigkeit. (Mein Dank an Jeff Moore, der mich geduldig auf die Dependency-Injection-Spur gebracht hat.) Wir nutzen noch nicht einmal Superglobals innerhalb der Pakete. Alles aus der Umgebung wurde in die Objekte kopiert, was Tests wirklich stark vereinfacht.

PM: Warum musste es PHP 5.4 sein? Wo liegt der Vorteil?

Jones: Als wir 2010 mit dem Aura-Projekt begonnen haben, nahmen wir uns PHP 5.3 vor, da es zu der Zeit die aktuelle PHP-Version war. Dann kam PHP 5.4 im Januar 2012, als sich noch fast alle Aura-Pakete in der Entwicklung befanden. Also dachten wir uns, wir könnten genau so gut PHP 5.4 anvisieren mit seiner verkürzten Array-Syntax und Callable Type Hint. Solche Dinge erscheinen klein, aber wenn man sie einmal einsetzt, sind sie so bequem (und ganz ehrlich: sie machen den Code hübscher ☺) Besonders für Closures und Traits gibt es mächtige Anwendungen, wenn man sie geschickt einsetzt.

PM: Du scheinst kleine Pakete zu mögen. Was hältst du vom Microframework-Ansatz, von den Ed Finkler am Anfang des Jahres propagiert hatte?

Jones: Ed hat starke Argumente, aber ich denke gar nicht mal, dass er so sehr für Microframeworks ist, wie er für Micro-PHP allgemein ist.

Damals, zu Zeiten von PHP 3, 4 und in den frühen 5.x-Tagen war „Framework“ ein schmutziger Ausdruck im PHP-Land. (Das Wort „CMS“ war aber in Ordnung.) Aber als Ruby on Rails erschien, war „Framework“ etwas Gutes. Eine Menge Entwickler sind darauf aufgesprungen, und wir machten dasselbe mit Solar.

Ich glaube, dass der Gang zurück zu einem Bibliothek-oriententen Ansatz eine natürliche Tendenz in der PHP-Welt ist. Frameworks sind nach wie vor viel wert, besonders für Entwickler am Anfang oder in der Mitte ihrer Karriere, oder für Teams, die einen standardisierten Entwicklungsprozess benötigen und die keinen Senior Architect unter sich haben. Erfahrene Entwickler hingegen möchten Bibliotheken selbst auswählen und sie wollen genau verstehen, was eine einzelne Bibliothek tut (und warum, und wie). Und sie wollen die Teile ersetzen, die sie nicht mögen. Das ist viel einfacher, wenn du unabhängige Bibliotheken hast, als wenn du ein monolithisches Framework hast.

PM: Wer in der Welt der PHP-Entwickler profitiert besonders von Komponenten-Frameworks?

Jones: Eine Menge PHP-Entwickler stecken fest in einer Codebasis, die sie nicht selbst erschaffen haben oder die sie nur sehr vorsichtig und langsam verbessern können, weil der Umsatz ihres Geschäfts davon abhängt. Für diese Entwickler steht ein Wechsel zu einem Framework gar nicht zu Debatte. Da das Aura-Projekt aus unabhängigen Komponenten besteht, gibt es diesen Entwickler die Option, nur einzelne Bestandteile auszuwählen, die sie für ihre bestehenden Projekte benötigen. Damit können sie behutsam die Qualität ihrer Codebasis steigern. Es ist einfacher, ein Projekt mit Aura stückchenweise zu refaktorisieren als mit einem monolithischen Framework komplett von vorne zu beginnen.

Kurz vor Ende des Gesprächs gingen wir auch auf die Konkurrenz ein: Symfony2 und Zend Framework 2 haben ebenfalls in diesem Jahr mehr oder weniger deutlich gemacht, dass sie ihre alten Framework-Monolithen zerschlagen. Diesbezüglich könnt Ihr schon bald mit einem Follow-up von unserer Seite rechnen, wo noch mehr Stimmen aus der Entwicklerwelt zu Wort kommen werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -