Construktor injection als Configuration auslagern
MB
- php
- programmplanung
moin community,
ich will Parameter in fester Reihenfolge übergeben, da komplexe Routinen es bekanntlich erwarten, wenn man die Routinen aufruft und füttert. IMO lohnt es sich einen "Pseudodatentyp" zu erstellen der Ordnung ins Parameter-Chaos bringt. Ein Beispiel:
class FooCFG {
public $bar;
public function __construct( $bar ) {
$this->bar = $bar;
}
}
für den Einsatz sähe es dann so aus:
new Foobar( new FooCFG( 'something' );
wenn man diesen weg fährt, IMO lohnt es sich an einer zentralen Stelle die Constructor-Injections zu verwalten …
Config::set( 'FooInit', new FooCfg( 'sonmething' ) );
new Foobar( Config::get( 'FooInit' ) );
ich beführchte ich denkle zu kompliziert aber nur so kriege ich das gut sortiert und strukturiert hin oder ist es zwingend notwendig wenn ein Framework-Ausbau komplexer wird?
vlg MB
Tach!
ich beführchte ich denkle zu kompliziert aber nur so kriege ich das gut sortiert und strukturiert hin oder ist es zwingend notwendig wenn ein Framework-Ausbau komplexer wird?
Manchmal muss man einfach tun und erst die Zukunft ergibt, ob ein Weg richtig war oder es anders besser geht. Wenn man die Konfiguration an einem Ort verwalten möchte, ergibt sich zwangsläufig, dass man ein Repository benötigt, in das man die konfigurierten Objekte oder die Konfigurationsdatenobjekte ablegt, um sie an anderer Stelle initialisiert holen zu können. Deine Config-Klasse ist in dem Fall dieses Repository.
dedlfix.
treffend formuliert. Dankeschön!!!
Moin,
es läuft auf Dependency Injection hinaus, weil die ConfigInstanz ja bereits vorhanden sein muß bevor Deine eigene FrameworkInstanz erstellt wird. Also wirst Du die Configinstanz in den Konstruktor zur Frameworkinstanz übergeben.
Wenn das Configobjekt jedoch eine Instanz der Klasse Config ist, darf sie auch eigene Methoden haben, womit sich statische Methoden (Klassenmethoden der Config Klasse) erübrigen.
Kompliziert wirds nämlich, wenn es mehrere Möglichkeiten zur Speicherung der Konfiguration gibt, also bspw. verschiedene Dateiformate (ini, xml, json, andere) oder die Konfiguration befindet sich in einer Datenbank. Und genau hier liegt die Begründung für den Verzicht auf statische Methoden. Ergo muss eine Instanz erstellt werden und zwar so, daß diese Instanz beim Aufruf $cfg->write();
als eine eigene Methode die Änderungen auch dahin zurückschreibt wo die CFG-Daten ursprünglich hergekommen sind und auch im selben Format versteht sich.
Schönen Sonntag.