nicht angemeldet
Hey Sven,
auch Dir herzlichen Dank für Deine Antwort!
Komponenten von bereits existierenden Frameworks oder anderen Drittanbietern sollen laut Aufgabenstellung nicht verwendet werden.
Wäre ja auch noch schöner, wenn man sich viel Arbeit spart und einfach fremden Code importiert... ;->
Allerdings :-)
Nur weil "fremde Frameworks" nicht benutzt werden dürfen, muss man sie ja nicht auch als Inspirationsquelle ignorieren.
Ich glaube das ist das, was dedlfix und jobo auch schon versucht haben mir klarzumachen. Aber irgendwie hab ich das immer "überlesen" :-) Aber Ihr habt ja alle recht: Als erstes werde ich mich jetzt mal mit verschiedenen Frameworks auseinandersetzen.
Wisst Ihr eigentlich, ob es laut den verwendeten Lizenzen (bspw. vom ZF) erlaubt ist, Methoden 1:1 zu übernehmen und "in ein neues Gewand" zu packen? Dann wären schon viele Probleme gelöst :-)
Nun hast du mit "Konfiguration" ausgerechnet das Themengebiet ausgesucht, das viele diskussionswürdige Aspekte enthält. "Die Konfiguration der Software" ist nämlich sowohl dynamisch (je nach eingelesener Datenquelle), als auch statisch (es kann nur eine Variante zur Zeit geben), sowohl global (die Konfiguration gilt überall gleich) als auch lokal (nicht jede Konfigurationsvariable ist überall gültig und/oder relevant) - und letztendlich ist immer die Frage: Wie kommt die nutzende Klasse konkret an die gewünschten Werte?
Ich muss gestehen, so genau habe ich darüber noch gar nicht nachgedacht. Wo ich das so lese, ist das Beispiel wohl tatsächlich unglücklich.
Wir sind da etwas naiv drangegangen und haben einfach gedacht, jede Anwendung braucht eine Konfiguration. Und eine Konfiguration ist für jeden recht einfach zu verstehen und man kann daran die generelle Vorgehensweise testen. So einfach, so blöd...
- Einzelne Klasse [...]
WENN ich die Konfiguration in einer einzelnen Klasse ablegen würde, dann darin direkt "eingemauert" als PHP-Code, und nicht von irgendwoher eingelesen. Die Methoden dieser Klasse erlauben dann den Zugriff auf die Werte, und eventuell kann man auch irgendwie umstellen, welche Variante tatsächlich ausgeliefert wird.
Wäre das nicht vielleicht eine gute Möglichkeit für einen Cache? Also wenn man zum Beispiel eine XML-Konfiguration einliest und die Klasse die Konfiguration anschließend als "reine PHP-Klasse" speichert. So würde man sich ja das parsen sparen - obwohl ich nicht weiß, ob das von der Optimierung her viel ausmacht.
- Vererbung [...]
Vererbung von Klassen ist dann schön, wenn:
- es mehr als eine erbende Klasse gibt (wenn das mal irgendwann "sein könnte", gilt: YAGNI)
YAGNI war mir bis gerade auch noch kein Begriff. Wieder mal für alle (laut Wikipedia): "YAGNI steht für “You Ain’t Gonna Need It”, zu deutsch: „Du wirst es nicht brauchen”". Verstanden!
[...]
- sich dadurch in einem Bereich nicht mehr als drei Vererbungsebenen ergeben (zuviel Vererbung macht den Code undurchsichtig und damit schwer wartbar): Foo_Bar_Baz extends Foo_Bar_Abstract, Foo_Bar_Abstract extends Foo_Abstract - mehr nicht. Entscheidend für die "Vererbungsebenen" ist allerdings, welche Trennstellen man definieren kann. Wenn Foo_Bar_Baz eine Klasse eines externen Frameworks ist, die man seinerseits nochmal erweitern will, dann wäre diese Vererbung wohl die zweite Ebene, weil "Bereich" sich nur auf den eigenen Einflussbereich bezieht, auch wenn man dadurch insgesamt vier Vererbungsstufen hat.
Auch gut zu wissen, an welchem Wert wir uns grob orientieren sollten.
Es ist übrigens sehr empfehlenswert, sich von Anfang an ein vernünftiges Namensschema zur Klassenbenennung zu definieren - insbesondere, weil man heutzutage definitiv Autoloading benutzen will. Für sowas gibts schon Standards, der einzig relevante für PHP dürfte "PSR-0" sein (PSR steht für PHP Standard Recommendation, die 0 ist die laufende Nummer). Das Zend-Framework setzt dieses Namensschema ein, und ich halte es für sehr empfehlenswert.
Du hast uns schon wieder ne Menge Arbeit abgenommen. Haben heute morgen noch darüber diskutiert, wie die Benennung bei der Verwendung von Namespaces aussieht. Hier übrigens der Link zu PSR-0.
[...] Die Frage wäre, ob Config_Ini von Config erben muss. Im Zend-Framework wird das gemacht, ich würde es aber nicht als zwingend ansehen.
Fällt Dir - außer bei DI - ein Fall ein, wo die Vererbung in diesem Fall keinen Sinn machen würde?
- "Helper"-Klasse [...]
Klingt wie Zend-Framework. :)
Also wieder mal ein Fall von "versucht, das Rad neu zu erfinden".
[...] Ich habe schon Designs gesehen, in denen ein leeres Interface (keine definierten Methoden) einfach nur "weil man es so macht" definiert und von einer einzigen Klasse implementiert wurde.
In so nem Fall würde sogar ich mich wundern, was das soll :-)
- Factory Method [...]
Klingt nicht wie das Factory-Pattern, sondern wie das Singleton-Pattern. Und DAS sollte man meiden! Es ist nämlich nicht gut testbar.
Singleton sollte das nicht sein. Hab mich wohl ein bisschen schwierig ausgedrückt.
- Dependency Injection (Verwendet der nun folgende Fall überhaupt dieses Pattern?) [...]
Dependency Injection ist, wenn ein Objekt zum Funktionieren ein anderes Objekt benötigt, welches es aber nicht selbst erzeugt, sondern von Außen reingereicht bekommt.
Wenn der Konstruktor des Objekts also selbst was instanziiert, dann ist das KEINE Dependency Injection.
So hat dedlfix das auch erklärt. Ich bin dabei, das umzusetzen. Danke für die Erklärung!
Auch hier ist wieder das Stichwort "Testbarkeit" ausschlaggebend. Wenn man ein Objekt testen will, dass von ganz allein andere Objekte instanziiert und benutzt, dann kann man das eigentliche Objekt nicht vollständig testen. Denn man muss auch kontrollieren können, ob und wie das zu testende Objekt sein inneres Objekt anspricht. Sowas geht nur, wenn man anstatt des echten inneren Objekts eine Testklasse hineintut, die die Methodenaufrufe registriert und mit vorgefertigten Resultaten antworten kann.
Sind das die "ominösen Mock-Objekte"?
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?Was ich bevorzuge: Dokumentation, Testabdeckung und Nutzung etablierter Standards, und nicht die hundertdreiundzwanzigste Neuerfindung eines MVC-Frameworks.
Ja, macht Sinn :-)
[...]
Existierende Frameworks angucken. Benutzen. Ideen erkennen. Und wenn's sein muss, dann nachbauen.
Damit werden wir uns jetzt erstmal beschäftigen!
Danke und Gruß,
Dennis