Cleancode, Dependency Injection oder wie stelle ich mich richtig an

[Uwe Raabe]

Zitat von Dejan Vu:

Delphi-Quellcode:

... finally
     FreeAndNil(FormDetail);
   end;

Ich würde da 'Release' verwenden. Soweit ich mich erinnere, ist das der bevorzugte Weg, ein Windows-Formular freizugeben.

Das ist eigentlich nur notwendig, wenn die Freigabe innerhalb eines Events des Forms erfolgt. Man würde sich ja sonst selbst die Füße wegschießen.

Allerdings genügt in diesem Fall auch ein simples FormDetail.Free;

[Dejan Vu]

Zitat von Uwe Raabe:

Das ist eigentlich nur notwendig, wenn die Freigabe innerhalb eines Events des Forms erfolgt.

Meine Erfahrung besagt, das das auch aus anderen Events heraus ein Problem ist. Aber vielleicht ist das Aberglaube.

[Stevie]

Zitat von Ralle1:

@Stevie: besonders Deine Lösung würde mich interessieren! Deine Denkansätze beim Delphi-Code-Camp haben mir grundsätzlich gut gefallen, nur hapert es mir hier im konkreten Beispiel bei der Umsetzung...

Danke - ich freu mich, wenn ich zumindest einen kleinen Denkanstoß geben konnte

Ist noch nicht die 100%ige Lösung, da mir die Abhängigkeit vom Detailform auf das Mainform noch nicht gefällt (siehe Kommentar im Source).
Außerdem wird durch das Fehlen einer Abstrakten Settings Klasse noch die konkrete Implementierung vom TRememberEdit benötigt - da sollte man dann noch eine abstrakte Klasse implementieren (ich weiß grad nicht, ob man auch Interfaces im OI verdrahten kann).

Den noch etwas unsauberen Code im Mainform hab ich mal so belassen, denn darum ging es ja nicht hauptsächlich.

[TiGü]

Zitat von Stevie:

Ist noch nicht die 100%ige Lösung, da mir die Abhängigkeit vom Detailform auf das Mainform noch nicht gefällt (siehe Kommentar im Source).
Außerdem wird durch das Fehlen einer Abstrakten Settings Klasse noch die konkrete Implementierung vom TRememberEdit benötigt - da sollte man dann noch eine abstrakte Klasse implementieren (ich weiß grad nicht, ob man auch Interfaces im OI verdrahten kann).

Den noch etwas unsauberen Code im Mainform hab ich mal so belassen, denn darum ging es ja nicht hauptsächlich.

Warum kennt bei dir die Mainform und die Detailform die ControlSettings für das RememberEdit?
Geht es nur darum, dass fancy im OI zu verdrahten?
Da fand ich meine Lösung sauberer.

[Dejan Vu]

Zitat von Stevie:

Ist noch nicht die 100%ige Lösung, da mir die Abhängigkeit vom Detailform auf das Mainform noch nicht gefällt (siehe Kommentar im Source).

a) Entkoppel doch einfach die Settings komplett von der Komponente
a.1) Lass das TFormDetail.FormCreate ein Settings.Load(RememberEdit) ausführen
a.2) Schreib eine TSettings-Komponente, klatsch die auf das TFormDetail und füge die 'RememberEdit'-Komponente der TSettings-Komponente zu (so macht das DevExpress mit seinem TPropertyStore oder wie das Teil heißt).
b) So, wie Du das schon angedacht hast: Settings => Datamodule

Ich find a besser, denn die Lösung geht mit allen Komponenten. Bei eurer bisherigen Lösung muss man zwangsweise für jede Komponente, die ihre Settings persistiert, eine Ableitung machen in meinen Augen.

[Stevie]

Zitat von TiGü:

Warum kennt bei dir die Mainform und die Detailform die ControlSettings für das RememberEdit?
Geht es nur darum, dass fancy im OI zu verdrahten?
Da fand ich meine Lösung sauberer.

Die Mainform kennt das, weil die Komponente drauf liegt
Die Detailform kennt es, weil die Main.pas im uses steht und man dann über RAD Mechanismen an das RememberEdit das Settings dingen eines anderen Moduls hängen kann - manche Leute brauchen das, daher mein Kommentar - ich brauch sowas persönlich nich, da es nur funktioniert, wenn man diese globalen Variablen in den Units stehen lässt. Ich würd des Setting als Property meines Detailforms machen und beim setzen die Properties anwenden. Braucht halt mehr Code, da das nicht automagically im Loaded passiert.

Zitat von Dejan Vu:

a) Entkoppel doch einfach die Settings komplett von der Komponente
a.1) Lass das TFormDetail.FormCreate ein Settings.Load(RememberEdit) ausführen
a.2) Schreib eine TSettings-Komponente, klatsch die auf das TFormDetail und füge die 'RememberEdit'-Komponente der TSettings-Komponente zu (so macht das DevExpress mit seinem TPropertyStore oder wie das Teil heißt).
b) So, wie Du das schon angedacht hast: Settings => Datamodule

Ich find a besser, denn die Lösung geht mit allen Komponenten. Bei eurer bisherigen Lösung muss man zwangsweise für jede Komponente, die ihre Settings persistiert, eine Ableitung machen in meinen Augen.

Die Anforderung war, das Settings Teil nur einmal zu haben, mit a) geht das nicht - bei DX zum Beispiel braucht auch jedes Form nen PropertyStore.

[Dejan Vu]

Zitat von Stevie:

Die Anforderung war, das Settings Teil nur einmal zu haben, mit a) geht das nicht

Doch. Version a1.

[Stevie]

Zitat von Dejan Vu:

Zitat von Stevie:

Die Anforderung war, das Settings Teil nur einmal zu haben, mit a) geht das nicht

Doch. Version a1.

Woher kommt im FormCreate denn das Settings her?

[Dejan Vu]

Zitat von Stevie:

Zitat von Dejan Vu:

Zitat von Stevie:

Die Anforderung war, das Settings Teil nur einmal zu haben, mit a) geht das nicht

Doch. Version a1.

Woher kommt im FormCreate denn das Settings her?

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.

Variante a.2) ist eben Old-School Delphi: "Für alles ne Komponente". Einfach, RAD, Chaos.

Allerdings muss man sich auch genau überlegen, was man da eigentlich umsetzen will.
Eine spezielle(!) Edit-Komponente, die ihre letzte Eingabe persistieren will, ist anders umzusetzen, als die Fähigkeit, beliebige Eigenschaften von Komponenten zu persistieren.

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.

[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.