Da ich die Abhängigkeit von den Controlsettings nur noch an einem Pattern habe (FormCreate), anstatt in zwei (FormCreate und jede Komponente), kann ich das nun durch Vererbung wegkürzen.
Bei meiner Lösung habe ich die Abhängigkeit zunächst aus der Komponente entfernt und mit einer abstrakten Basisklasse wäre die Abhängigkeit an genau einer Stelle. Und wenn ich sie nur dort verwende, kann ich auf das Globalgedöns auch ganz verzichten.
Ganz ohne Abhängigkeiten von den Controlsettings *kann* es gar nicht funktionieren, weil die Verwendung Teil der Lösung ist. Ergo haben wir irgendwo mindestens ein 'uses ControlSettings'. Je weniger Stellen, desto besser. Ganz Ohne geht nicht, mehr als eine Abhängigkeit ist aber beinhae schon zuviel, also:
Delphi-Quellcode:
Type
TBaseControlSettingsForm = Class(TForm)
Private
Procedure LoadSettings;
Public
Procedure FormCreate(Sender : TObject); // lädt die Properties der Controls über die ControlSettings-Klasse
end;
...
// TFormDetail = Class (TBaseControlSettingsForm);
// TFormMain = Class (BaseControlSettingsForm);
Procedure TBaseControlSettingsForm.FormCreate(..);
Begin
LoadSettings;
End;
So würde ich das lösen. Natürlich sind die Formulare in einzelnen Dateien. Habe das nicht SOLID-mäßig abgeklopft, aber von meinem alten Bierbauchgefühl würde ich sagen, das es ausreichend ordentlich ist.
Ich kann der BasisForm auch eine 'UserID' spendieren, sofern diese systemimmanent ist, also integraler und unverzichtbarer Bestandteil des (Form-)Frameworks. In meinem Ansatz ist z.B. die Verwendung der Controlsettings systemimmanent, weil eben genau so gewollt.
Übrigens, wenn man DI konsequent verwendet, tippt man sich einen Wolf und erzeugt wunderbar testbaren Code, der aber so grottig (weil schlecht lesbar), das man kotzen könnte. Den Weg muss man aber dort gehen, wo Abhängigkeiten durch Faulheit entstehen würde.
Aber wenn die Abhängigkeit -tolles Wort- systemimmanent (und nur dann) ist, sollte man den DI-Firlefanz außen vor lassen.