nicht angemeldet
Hallo zusammen!
Aufgabenstellung:
Für ein neues Projekt soll als Grundlage eine Art "Mini-MVC-Framework" entworfen werden, welches vorerst nur die wichtigsten Komponenten zum Erstellen einer Anwendung enthalten soll. Natürlich soll es auch zur Lösung zukünftiger Herausforderungen einfach erweiterbar sein.
Komponenten von bereits existierenden Frameworks oder anderen Drittanbietern sollen laut Aufgabenstellung nicht verwendet werden.
Außerdem soll dem Framework die gerade aktuellste PHP-Version (derzeit 5.3.6) zugrundegelegt und der Funktionsumfang wie Namespaces, etc., auch genutzt werden.
Einleitung:
Da das Framework von der Implementierung her natürlich in sich konstistent sein und auch in Zukunft noch den Anforderungen gerecht werden soll, stellt sich jetzt die Frage, welche Design Patterns für viele Komponenten verwendet werden sollen. Eine zum jetzigen, frühen Zeitpunkt durchdachte Wahl erspart später sicherlich viel Arbeit.
Beispiele:
Um das "Problem" zu verdeutlichen, möchte ich von einer Klasse ausgehen, die Konfigurationsdaten aus verschiedenen Quellen (z.B. INI, XML, ...) lädt und anschließend für späteren Zugriff speichert. Folgende Möglichkeiten zur Umsetzung haben wir uns bisher überlegt:
1. Einzelne Klasse
Die Klasse enthält lediglich je eine eigene Funktion für die möglichen Quellen.
2. Vererbung
Unterklasse ist beispielsweise "Ini", Oberklasse "Config". "Ini" parsed die Ini-Datei und speichert die Konfigurationen wegen der Vererbung "quasi in sich selbst". "Config" ist als abstrakt definiert, sodass nur "Ini" direkt aufgerufen werden kann. Es werden also die einzelnen Funktionen aus 1) in eine eigene Klasse ausgegliedert.
3. "Helper"-Klasse
Klasse "Ini" implementiert eine Interface "Sources". Im Konstruktor von Klasse "Config" wird der Quellen-Typ ermittelt und dementsprechend eine der Quellen-Klassen, also z.B. "Ini", aufgerufen, welche anschließend ein Array von Konfigurationsdaten zurückliefert. Dieses Array wird anschließend von "Config" gespeichert. ("Ini" erbt nicht von "Config")
4. Factory Method
Eine Mischung aus 2) und 3). Unterschied: Oberklasse "Config" besitzt eine statische Fabrik-Methode. Statt wie in 2) muss diese bemüht werden, den richtigen "Ansprechpartner" zu finden und nicht der Konstruktor. Der Konstruktor ist in diesem Fall mindestens "protected".
5. Dependency Injection (Verwendet der nun folgende Fall überhaupt dieses Pattern?)
Eine Mischung aus 3) und 4). Unterschied: Hier bestimmt der Konstruktor von "Config", welcher Quellen-Typ vorliegt und instanziiert die entsprechende Helfer-Klasse. Die Helferklasse erhält eine Referenz von "Config", in die sie mittels der Methoden von "Config" Eigenschaften speichern kann.
Überleitung:
Das sind verschiedene Möglichkeiten, die wir uns überlegt haben, an die Sache ranzugehen. Alle haben sicherlich Vor- und Nachteile und es gibt sicher auch noch andere Möglichkeiten. Wir sind etwas verwirrt!
Frage:
Also nun meine Frage an Euch: Welche Möglichkeiten haltet Ihr noch für denkbar? Was haltet Ihr von den oben genannten Möglichkeiten? Welche Vor- oder Nachteile fallen Euch ein? Was würdet Ihr ganz persönlich bevorzugen, wenn Ihr mit einem Framework arbeitet?
Wir freuen uns über alle Meinungen, Anmerkungen, Vorschläge oder was-auch-immer, was uns bei unserer Entscheidungsfindung behilflich sein könnte.
Solltet Ihr Fragen zu oben beschriebenem haben, habe ich mich unklar ausgedrückt oder etwas vergessen, so schreibt bitte einfach kurz!
Ich danke Euch im Voraus für Eure Antworten,
Dennis
Ps: Sorry, dass das wieder so ein langer Text geworden ist.