Cleancode, Dependency Injection oder wie stelle ich mich richtig an

[Stevie]

Zitat von Dejan Vu:

Von der einen Instanz natürlich, die ja gefordert ist. Der einzige Unterschied zwischen deiner angedachten Lösung mit dem Datenmodul und meiner Variante (a1) ist die Entkopplung der Settings von der Komponente. Anstatt also die Komponente sich selbst laden zu lassen, wird das nun von außen angestoßen. Klar, muss man dann jeweils machen. Gut aufgehoben ist so eine Settings-Komponente natürlich zentral, in einem Datenmodul o.ä.

Ich finde meine Variante einfach wiederverwendbarer und praktischer, weil, wie schon gesagt, keine SonderlockenIchKannMitSettingskomponenten erstellt werden müssen. So ein Settingsdingens kann mit Jedem.

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

Grundsätzlich stimme ich dir zu, was das Speichern/Laden der Settings angeht (Stichwort SRP). Aber auch dann muss man entweder loader/saver haben, die speziell für unterstützten Komponenten sind oder die Komponenten müssen über irgendeinen Mechanismus (z.B. Attribute) mitteilen, was sie denn gespeichert haben möchten.
Ansonsten artet das Settingsdingen irgendwann in einem Riesengroßen if then else Chaos aus, in dem überprüft wird, welche Komponente ich denn gerade speichern möchte inklusive der abhängigkeit des Settingsdingen auf alles, was es kann.

Dennoch: Was wollen wir erreichen? Lose kopplung, um einzelne Teile zu testen ohne den gesamten Klump deiner Anwendung dran hängen zu haben. Sofern man das Settingsdingen noch abstrahiert, so dass ein TRememberEdit nicht mit der konkreten Implementierung arbeitet sondern mit einer Abstraktion habe ich das erreicht. Ebenfalls ist mein konkretes TSettings nicht von irgendwelchen global States abhängig und könnte auch ohne UserId seine Settings in localappdata oder sonstwo hin ballern. Wie und wo ich dann diese beiden Kollegen miteinander bekannt mache ist fast nebensächlich.

Zitat von Dejan Vu:

Soweit ich mich erinnere, ging es im Eingangspost um ein PageControl, das Eigenschaften mit Hilfe einer User-ID als Schlüssel in einer DB ablegen will und da dachte ich, wir sprechen über Letzteres. Im Beispiel mit dem RememberEdit wäre vermutlich die hier vorliegende Variante passender.

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