Hey Sven,
- 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.
Die Gegenfrage wäre an dieser Stelle dann: Warum überhaupt erst XML? Das ist vom Format her ja auch nicht wirklich pflegeleicht, man muss mit Sachkenntnis die Konfiguration vornehmen und darf keine Syntaxfehler einbauen - da kann man doch im Prinzip direkt PHP-Code schreiben und spart sich das Parsen des XML.
durch das "studieren" von ein paar (PHP-)Frameworks hat sich bei mir vielleicht festgesetzt, dass dies ein nötiger und wichtiger Schritt sei - oder besser: INI, XML und Co. sind "state of the art". Deine Gegenfrage bringt mich allerdings zum Nachdenken.
- 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!
Die Tatsache, dass dieses "Muster" ein eigenes Akronym bekommen hat, deutet schon darauf hin, dass sich viele Programmierer mehr an der Schönheit der implementierten Features delektierten, damit aber unnötige Komplexität ins Haus holten, und im Endeffekt in Schönheit starben (oder zumindest ihr Projekt).
YAGNI symbolisiert Verzicht: Keine "kann man bestimmt später mal gut brauchen"-Features, kein "ist architektonisch aber viel besser erweiterbar auf das, was später mal kommen könnte"-Zuckersahnehäubchen. Relevant ist, was aktuell gefordert ist. Das muss erfüllt werden, mehr nicht.
Ich werde es mir zu Herzen nehmen!
[...] 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?
Vererbung führt ja dazu, dass gemeinsamer Code in beiden Klassen verfügbar ist. Wenn ich Zend_Config als Container und Zugriffsmanager verstehe, der mit definiert aufgebauten Arrays gefüttert wird, und Zend_Config_Ini der Einleser für INI-Dateien ist, der genau solche Arrays aufbaut, dann sehe ich erstmal wenig Grund für gemeinsamen Code.
Das macht natürlich Sinn. Also wäre das ein Fall für eine externe (Einlese-)Klasse, Dependency Injection oder artverwandte Muster?
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"?
Genau. In der PHP-Welt wirst du zwangsläufig auf PHPunit treffen als einzigem verbreiteten Test-Framework, allerdings auf mehr als ein Mock-Objekt-Framework. PHPunit bringt dafür Funktionalität mit, die aber zu Recht kritisiert wird als zu umständlich konfigurierbar.
Gut zu wissen, dann werde ich mich damit mal ein bisschen beschäftigen. So wie's aussieht, wird das aber wohl ein bisschen dauern.
Alternative dazu wäre Mockery. Ist noch im Entstehen (Version 0.7.0), setzt zwingend PHP 5.3 voraus, sieht aber von der Mock-Syntax her sehr gut aus.
Auch hier danke für den Link. Das wird aber auch erstmal etwas dauern, bis ich mich da eingelesen habe.
Und auch Dir danke ich wieder mal für Deine tolle Hilfe!
Gruß, Dennis