Konfiguration auslagern

[dedlfix]

Tach!

ich z.B. nenne eine Klasse Foo mit Namespace Config, sodass ich Config\Foo in der Form Zugriff habe. Ich sehe keinen Sinn darin eine Klasse FooCfg zu nennen, wo sie ja schon im Namespace Config enthalten ist.

Auch gut. Das war halt so nicht zu erkennen und Namespaces kamen mir grad nicht in den Sinn.

Zur meiner Frage: warum siehst du keinen sin darin das man mit statischen Klassen Konfigurationsparameter allerart übergeben kann? Ich hab da ein bisschen rum gesponnen.

Moment, du musst meine Aussagen in neuem Licht betrachten, ich hatte ja die Sache mit dem Namespace nicht beachtet.

namespace Config;
class Config {
  private static $settings = []
  protected function set( $key, $value ) {
    self::$settings[ $key ] = $value;
  }
  protected function get( $key ) {
    return self::$settings[ $key ];
  }
}

namespace Config;
class Foo extends Config {}

Wenn es sich also reinweg um die Konfiguration dreht, dann ist das mit dem Vererben eine der möglichen Varianten. Config enthält generelle Methoden, die in Config\Foo oder Config\Router oder anderen spezialisierten derartigen Klassen benötigt werden.

für mich eleganter und technisch genauer. Für konstruktive Kritik bin ich immer zuhaben.

Eine andere Variante ist, dass man statt der Config-Klasse ein Repository erstellt und die eigentlichen Daten in POPO-Klassen^[1] verwaltet, also nackige Klassen, die lediglich Eigenschaften für die Daten enthalten. Das Repository bekommt statt der allgemeinen set- und get-Methode konkretere Methoden, die mehr auf die Anwendung zugeschnitten sind. Zum Beispiel gibMirDatenbankZugangsdaten() oder gibMirLoggerKonfiguration(). Das Problem mit dem generischen get/set ist, dass man nun einen String braucht, um anzugeben, welche Daten man lesen oder schreiben möchte. Diese so genannten Magic Strings steuern nun den Programmablauf. Man muss ihre Namen wissen um zum gewünschten Ergebnis zu kommen und bekommt meist keine Autovervollständigung dafür. Diese generische Weise hat jedoch die Eigenschaft, dass man ohne irgendwelche (POPO-)Klassen anzupassen, beliebige Werte hinzufügen kann. Doch die Frage ist, ist es diese Flexibilität wert, dass dabei die Autovervollständigung und damit eine Hilfe zur Tippfehlervermeidung auf der Strecke bleibt.

Man könnte die Betrachtung auch aus einem anderen Blickwinkel anstellen. Deine Variante hat gewisse Ähnlichkeiten mit einem Active-Record-System. Eine schwergewichtige Klasse kümmert sich um die Datenhaltung und vereint Daten und Methoden des Zugriffs. Mein anderer Vorschlag versucht diese direkte Beziehung zu vermeiden und trennt die eigentlichen Datenobjekte von der Klasse, die sich um die Verwaltung kümmert.

dedlfix.

---

1. Plain Old PHP Object ↩︎