Cleancode, Dependency Injection oder wie stelle ich mich richtig an

[Dejan Vu]

Zitat von Stevie:

Woher weiß das Detailsform denn nun von der einen Settings Instanz? Constructor Injection? Zuweisen über eine Eigenschaft und Anstoßen des Settings ladens?

Die Settings sind in einem Datenmodul.

Delphi-Quellcode:

Procedure TFormDetail.FormCreate(Sender : TObject);
Begin
  myDataModule.Settings.Load(RemberEdit);
  // bzw.
  For control in Controls do myDataModule.Settings.Load(control);
End;

Um es kurz zu machen: Deine Lösung ist vollkommen ausreichend, ich wollte noch das SRP einbringen, das ist alles. Wie man den Rest löst (muss ich dir ja nicht erzählen), hatte ich weiter oben ausgeführt (Die Geschichte mit einer Factory, einer FactoryFactory usw.), nur hat das wohl keiner gelesen oder verstanden oder beides.

Zitat:

Ob nun Pagecontrol oder Edit, oder Datenbank oder Textdatei spielt eigentlich keine Rolle - ich glaube so viel abstrahieren kann hier jeder.

Habe ich mich misverständlich ausgedrückt? Mein Einwand war:
Will ich (nur) eine Komponente, die ihren inneren Zustand irgendwo persistiert, oder will ich eine generelle Möglichkeit, Komponenten bzw. Klassen zu persistieren?
Im ersten Fall ist die Persistierung Bestandteil der Komponente ("Wer ist zuständig?" "Die Komponente!") Im zweiten Fall ist die Persistierung Bestandteil meines Frameworks, mit allen Vorteilen.
Mit meinem Fokus auf die Eingangsfrage war nicht das Pagecontrol gemeint (das ist wirklich wurst), sondern die für mich dann doch im Vordergrund stehende Möglichkeit, Komponenten generell zu persistieren. So hatte ich die Frage jedenfalls verstanden. Und dann wäre dein Vorschlag eben verbesserungswürdig. Das kannst Du natürlich anders sehen, wenn Du magst.

[Stevie]

Zitat von Dejan Vu:

Zitat von Stevie:

Woher weiß das Detailsform denn nun von der einen Settings Instanz? Constructor Injection? Zuweisen über eine Eigenschaft und Anstoßen des Settings ladens?

Die Settings sind in einem Datenmodul.

Delphi-Quellcode:

Procedure TFormDetail.FormCreate(Sender : TObject);
Begin
  myDataModule.Settings.Load(RemberEdit);
  // bzw.
  For control in Controls do myDataModule.Settings.Load(control);
End;

Genau da sitzt ja der Hase wieder im Pfeffer, denn auch das ist leider wieder ein Singleton bzw global state (nett versteckt und durch RAD unheimlich sexy verpackt, da man es schön fein im OI an bestehende Komponenten stecken kann). Oder wenn man nicht auf RAD und den Firlefanz steht, kann man immernoch wuppdi mal ebend im Code drauf zugreifen, tut ja nich weh.

Nu hab ich in jedem Form, wo ich meine Settings laden/speichern möchte als Abhängigkeit das myDataModule - nicht falsch verstehen, das hab ich in der Lösung, die ich oben gezeigt habe, auch. Nur das als irgendwie besser zu verkaufen ist Augenwischerei, da es dasselbe in grün ist.

Deshalb stell ich mal eine Behauptung auf bis mich jemand vom Gegenteil überzeugt:
"DI ist die einzige Möglichkeit, Abhängigkeiten voneinander zu entkoppeln."

Ob man das immer muss oder manchmal auch der halbe Weg reicht, steht wie so oft bei solchen Diskussionen auf einem anderen Blatt.

[Dejan Vu]

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.