nicht angemeldet
Moin!
Du dürftest wenig Widerspruch ernten - außer vielleicht von denen, die den Sinn von OOP noch nicht so wirklich verstanden haben. Schließlich entspricht deine Vorgehensweise durchaus guten Prinzipien, wie sie anerkannt als "best practice" in der Fachwelt gehandelt werden.
Einerseits schön zu hören, auf der anderen Seite würden mich auch noch andere Sichtweisen interessieren. Man hört ja immer wieder, OOP sei zu langsam, PHP bietet auch so schon genug Funktionen, ...
Wenn etwas langsam ist, dann ist das nicht OOP, sondern PHP an sich.
Und um über den Sinn oder Unsinn von OOP nachzudenken, sollte man sich mal irgendeine beliebige, aber naturgemäß etwas umfangreichere PHP-OOP-Anwendung nehmen und überlegen, was denn passieren würde, bzw. was das Resultat wäre, wenn man sämtliche Klassen wegließe und nur noch die zugrundeliegenden Funktionen und Eigenschaften hätte.
Nach meiner Ansicht würde das große Chaos ausbrechen, weil die Gruppierung von Funktionen in sinnvolle Sachzusammenhänge, die durch das Erstellen einer Klasse entsteht, vollkommen verloren geht. Man erhält also am Ende einen riesigen Pool von schlichten Funktionen, die alle gegenüber jeder anderen Funktion sichtbar sind. Es gibt keinerlei Möglichkeit, das einzuschränken, es gibt auch keine Möglichkeit, einer Funktion schon direkt im Parameter-Teil mitzuteilen, dass die ihr übergebenen Parameter gewissen Anforderungen zu erfüllen haben, also Objekte bestimmter Klassen sein müssen.
Was leistet OOP noch? Vererbung. Was spart man sich damit? Codeduplizierung. Eine Funktion kann nur schwerlich in den entscheidenden Punkten leicht modifiziert werden, ohne dass der Code der zugrundeliegenden Funktion nicht komplett kopiert werden müsste. Und wenn es doch ginge, würde man die Basisfunktion vermutlich in zwei oder drei Einzelteile aufbrechen müssen, um den relevanten Part dann durch eine Anpassung zu ersetzen. Insgesamt erhielte man ein sehr unübersichtliches Gebilde von diversen Funktionen.
Und wollte man diese Funktionen dann doch - durch ihre Namensgebung - sachlich gruppieren, würde man eben genau bei einer Vorstufe von objektorientierter Programmierung landen, d.h. man hätte alle Nachteile der rein funktionsorientierten Programmierung in PHP, ohne die Vorteile der objektorientierten Programmierung nutzen zu können.
Objektorientierte Programmierung dreht sich nicht um das "Auto-Objekt" mit dem eingebauten "Motor-Objekt", der "color"-Eigenschaft des Autos und den Variationen "Sportwagen" und "Lastwagen" dieses Objekts. Das sind alles Bildnisse, die dem Anfänger irgendwie ein Gefühl vermitteln sollen, dass er es hier mit Real-Welt-Objekten zu tun hat, indem reale Objekte verwendet werden, um das komplett virtuelle Objektorientierte zu vermitteln. Ich halte diese Metaphern eher für schädlich, denn in der realen OOP gibt es nur sehr selten Auto-Objekte mit Motor-Objekten, die tatsächlich echte Autos und Motoren darstellen.
Stattdessen sollte man OOP lieber begreifen und darstellen als einen Weg, seinen eigenen Code besser zu organisieren, effizienter zu nutzen, und leichter zu verstehen. Denn genau das ist das eigentliche Problem, welches von OOP besser gelöst wird, als von dem funktionsorientierten Ansatz.
Allerdings: Ohne Frontcontroller - wie soll das gehen? Irgendwas muss an der Stelle doch immer die Kontrolle übernehmen.
Da hast Du schon recht. Allerdings ist der Front-Controller bei mir eine obere Instanz: Er holt sich die Anfrage und ermittelt, welcher Controller und welche Aktion aufgerufen werden muss. Diese werden dann ausgeführt und geben die Kontrolle zurück zum Front-Controller, der dann die Daten sendet.
Einige Leute schwören aber darauf, dass es keinen Front-Controller in meinem obigen Sinne gibt. Vielmehr gibt es nur einen Router oder ähnliches, der den Controller und die Aktion aufruft und diese dann "auf sich allein gestellt sind".
Der Router gehört sicherlich mit in den Frontcontroller-Ablauf hinein. Bei deinem Frontcontroller ist das Routing halt statisch. Trotzdem muss es irgendeine Instanz geben, die letztendlich den eigentlichen Controller aufruft, nachdem der abzuarbeitende Request analysiert wurde.
Das genau ist für mich der Frontcontroller.
- Sven Rautenberg