dedlfix: $GLOBALS oder Static für Konfigurationen?

Beitrag lesen

Tach!

um Konfigurationen in einem Framework zu setzten, kann man ein Superglobale assoziatives Array verwnden $GLOBALS oder eine Klasse Config::get() - mein Wissensstand.

Frage: Was sind "Pros" und "Cons" dieser beiden Methoden?

Es ist kein Unterschied, ob du eine globale Variable oder ein Singleton verwendest. Das läuft prinzipiell auf dasselbe hinaus.

Die generelle Frage ist jedoch, möchtest du einen globalen Status, an dem sich Hinz und Kunz bedienen und beliebig Änderungen vornehmen können? Oder möchtest du mehr Kontrollmöglichkeiten haben und stattdessen getreu dem Prinzip "Don't look for things" auf Dependency Injection setzen und all das übergeben, was die Komponenten für ihre Arbeit brauchen.

Letzteres hat den Vorteil, dass du als Verwender bereits im Konstruktor sehen kannst, was die Klasse benötigt und nicht umhinkommst, diese Voraussetzungen zu erfüllen, bevor du die Klasse verwenden kannst. Wenn die Klasse stattdessen selbständig umherschaut und sich das benötigte Zeug zusammensucht, musst du anderweitig wissen, was du und an welcher Stelle du es bereitzustellen hast, damit die Klasse arbeiten kann.

Nebenfrage: ich habe aus SelfHTML kreisen gehört das es nicht gut sei, Superglobale Variablen zu verwenden. Bei globale Variablen kann ich nur erfahrungsgemäß zustimmen, aber bei einem Superglobalen assoziativem Array wie $SESSION oder $SERVER frage ich mich warum?

Ob global oder superglobal ist in der Hinsicht ob gut oder schlecht kein Unterschied. Das muss im Zuge der obigen Frage geklärt werden.

$_SESSION und $_SERVER und die anderen von PHP bereitgestellten Datenstrukturen haben aber eine Sonderrolle, als dass sie spezielle Informationen enthalten und/oder als Datenspeicher dienen. Als solche sind sie eher mit dem DBMS oder dem Dateisystem zu vergleichen, das auf ähnliche Weise die Aufgabe hat, Daten bereitzustellen und/oder zu speichern.

Da wäre für deine Architektur des Frameworks zu klären: Brauchen deine Komponenten das Wissen, dass solche Datenstrukturen existieren? Oder sollten sie nicht lieber die Daten in allgemeiner Form entgegennehmen, und eine spezielle Komponenten kümmert sich um den eigentlichen Zugiff auf die Datenquelle.

Beispielsweise sollte sowas deiner Geschäftslogik egal sein. Die soll lediglich die Daten gemäß Anforderung verarbeiten. Wo diese herkommen, spielt für sie keine Rolle. Und wenn sich morgen ändert, dass sie woanders gespeichert werden, dann musst du nur den Zugriffsservice ändern oder austauschen, nicht aber durch die gesamte Geschäftlogik durchlaufen und schauen, wo überall ein direkter Zugriff auf die Ressourcen eingebaut ist.

dedlfix.