Herzstück ist eine Interface, eine Routing-Table und eine flache Klassenhierarchie. Charakteristisch ist die Bindung von URLs an eine Subklasse und das steht alles auf meinen Seiten.
Das sind zwei wunderbare Beispielsätze für Technobabble, hohe Fachwortdichte, aber zumindest ich kann quasi keinerlei Inhalt entnehmen (und nein, das liegt nicht an meiner Programmierunerfahrenheit, mit den von dir genannten Jahreszahlen kann ich durchaus mithalten).
Doch, genau daran liegt es. Und noch was ist mir beim Entwickeln meines FW klar geworden: Lass Dich nicht beeirren und nicht durch Fachbegriffe verwirren. Mein FW ist letztendlich ein Ergebnis meiner eigenen Beharrlichkeit und meines Selbstvertrauens. Letzteres ist ein ziemlich starkes Motiv und auch das Alles Entscheidende.
Kommen wir mal zu einer einfachen Sache, die Bindung eines URLs an eine Subklasse. z.B. in einer INI-Datei
; URL, Klasse u.a. Attribute
[/sitemap.xml]
class=Sitemap
no_cache=1
no_sitemap=1
Diese u. weitere URLs bilden, nachdem die ini im RAM gelandet ist, den sog. urlmap oder auch Routing-Table genannt. Ich darf die ini natürlich auch Projektverwaltung nennen, weil da alles, was sich auf einer Domäne befindet, drinsteht.
So reicht zur Qualitätssicherung und Debug ein flüchtiger Blick in den Response-Header, um zu sehen, an welche Klasse ein URL gebunden ist, der Customheader lautet x-class.
Nachdem also die Klasse feststeht, wird Sitemap.pm kompiliert und eine Instanz dieser Klasse erstellt. class Sitemap wiederum erbt von package main ein Interface. Das sind ein paar Methoden, die nur in einer bestimmten Reihenfolge aufgerufen werden müssen wobei in jeder dieser IF-Methoden die Instanz mit einer Reihe weiterer Attribute verfügbar ist.
Dependency Injection
Bei der Instanzerstellung werden weitere Klassen kompiliert und wiederum deren Instanzen eingbunden. Z.B. eine Instanz der Klasse CGI womit Requestparameter befragt werden können und eine Instanz der Klasse SESSION kurz class SES.
Das Reinschmacken dieser fremden Objekte in mein FW-Objekt nennt sich Aggregation. Das passiert im Moment der Erstellung meines FW-bjekts als Instanz der an den URL gebundnen Subklasse class=Sitemap im Beispiel. Das FW objekt hat also die Attribute SES und CGI. Delegation ist, wenn eine zum FW-Objekt also zur eignen Subklasse gehörige Methode über solche inneren Instanzen Methoden der fremden Klasse aufruft. Z.B. $self->{SES}->write(); um die Sessiondaten auf die HDD zurückzuschreiben. Und Lazy Delgation ist, wenn Instanzen nicht verwandter Klassen später, also erst zur Laufzeit in das FW-Objekt als Attribut reingeschmackt werden. Gewöhnlich im Rahmen einer Factory.
Warum braucht die SESSION eine Klasse?
Ganz einfach: Weil es eine Methode geben muss wo die Daten persistent macht. Und die muss wissen wo die Daten hingehören, auf HDD oder MySQL oder halt woandershin. Auf diese Art und Weise sind die Layer klar voneinander getrennt und es gibt klar definierte Schnittstellen.
Das ist im Prinzip schon alles. Logisch: Wenn ich nur die Config-Daten brauche, muss das Attribut {CFG} an keine Klasse gebunden sein. Will mein FW-Objekt jedoch CFG-Daten persistent machen, muss das Attribut {CFG} bzw. die Daten in dieser Referenz an eine Klasse gebunden sein, denn die Klasse definiert den Speicherort. Perl realisiert sowas über tie() das bindet eine Variable an eine Klasse und das geht auch in PHP zu machen wenn auch viel umständlicher.