hi,
ah so ähnlich habe ich das auch in meinem Projekt wie du aber nicht so perfekt und ich wusste nicht dass das URL-Routing heißt. Besten Dank für die Aufklärung :-)
Woanders hab ich das auch als URL-Mapping gelesen. Was natürlich nicht heißt, dass 500 verschiedne URLs 500 verschiedene Subklassen benötigen. Wen der Unterschied nur die Template-Datei ist, na dann wird das eben durch eine Attribut file=datei.html gesteuert.
Und wenn Formular-Eingaben, Ajax, XMLRPC, REST, SOAP o.a. beliebige Webservices über einen bestimmten URL laufen soll, kann ich auch mit dem Attribut interface=xmlrpc den URL lebendig (interaktiv) machen oder einfach nur dynamische Inhalte einbauen.
Was den AutoLoader betrifft: Ich lade damit keine Klassen sondern Methoden im Rahmen einer Factory. Und diese Methoden können on Demand zur Laufzeit weitere Klassen einbinden, z.B. MySQL-Verbindungen, Serializer, IO::File, wo Du wolle. GGf. erfolgt in diesen Methoden eine Aggregation von Instanzen nicht verwandter Klassen. Factory heißt ja, dass eine eigene Methode Instanzen erstellt; die jedoch können unsichtbar in der ausgelagerten Methode verbleiben oder werden zum Attribut der eignenen Instanz gemacht, nämlich dann wenn sie später noch einmal gebraucht werden.
Es gibt verschiedene Konzepte. An meinem FW hab ich fast 10 Jahre gebaut. Aber nicht am CODE an sich, sondern am Konzept. Und dabei bin ich 2x in einer mächtigen Sackgasse steckengeblieben, Gründe waren beidesmal dieselben: Zuviel CODE musste auf einmal kompiliert werden und die Übersicht ging flöten.
Lösung ist eine flache Klassenhierarchie und klare Abgenzung der Namespaces bei gleichnamigen Methoden. Und die Erkenntnis, dass praktische OOP NICHT das ist, was Dozenten vermitteln.