AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Cleancode, Dependency Injection oder wie stelle ich mich richtig an

Cleancode, Dependency Injection oder wie stelle ich mich richtig an

Ein Thema von Ralle1 · begonnen am 13. Mai 2014 · letzter Beitrag vom 15. Mai 2014
Antwort Antwort
Seite 3 von 4     123 4   
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
10.934 Beiträge
 
Delphi 12 Athens
 
#21

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 12:09
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;
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#22

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 13:33
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.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#23

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 14:01
@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.
Angehängte Dateien
Dateityp: zip DemoKomponente.zip (163,5 KB, 11x aufgerufen)
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.058 Beiträge
 
Delphi 10.4 Sydney
 
#24

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 14:30
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.
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#25

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 14:31
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.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#26

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 15:09
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.

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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#27

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 15:16
Die Anforderung war, das Settings Teil nur einmal zu haben, mit a) geht das nicht
Doch. Version a1.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#28

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 15:18
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?
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#29

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 15:56
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.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#30

AW: Cleancode, Dependency Injection oder wie stelle ich mich richtig an

  Alt 14. Mai 2014, 16:58
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.

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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (14. Mai 2014 um 17:03 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:48 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz