|
Trennung von GUI und Logik, wie geht ihr vor?
Hallo zusammen,
in diversen Themen hier taucht ja immer wieder die Trennung von GUI und Logik auf. Mich würde es mal interessieren wie ihr dabei vor geht. Beispiel: Ein Formular mit zwei Edits, einem Button und einem Label.
Delphi-Quellcode:
Eine Klasse mit einer "extrem schwierigen" Berechnung: 8-)
unit uMain;
interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, uAddition, StdCtrls; type TForm1 = class(TForm) EditZahl1: TEdit; EditZahl2: TEdit; ButtonAddition: TButton; LabelErgebnis: TLabel; private { Private-Deklarationen } public { Public-Deklarationen } end; var Form1: TForm1; implementation {$R *.dfm} end.
Delphi-Quellcode:
Vielen Dank schon mal für euer Mitmachen!
unit uAddition;
interface type TAddition = class private FErgebnis: Integer; public function Addition(Zahl1, Zahl2: Integer): Integer; property Ergebnis: Integer read FErgebnis; end; implementation { TAddition } function TAddition.Addition(Zahl1, Zahl2: Integer): Integer; begin FErgebnis := Zahl1 + Zahl2; Result := FErgebnis; end; end. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Meine Klasse sähe so aus:
Delphi-Quellcode:
und dann würde ich die Properties an die Edits und das Label binden und die Methode an den Button
type
TAddition = class private FErgebnis: Integer; public procedure Addition; property Zahl1: Integer read FZahl1 write FZahl1; property Zahl2: Integer read FZahl2 write FZahl2; property Ergebnis: Integer read FErgebnis; end; |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Ok, damit sieht dein ButtonOnClick so aus oder?
Delphi-Quellcode:
Dies sollte doch eigentlich auch vermieden werden, wegen Spaghetticode.
procedure TForm1.ButtonAdditionClick(Sender: TObject);
begin FAddition.Zahl1 := StrToIntDef(EditZahl1.Text, 0); FAddition.Zahl2 := StrToIntDef(EditZahl2.Text, 0); FAddition.Addition; LabelErgebnis.Caption := IntToStr(FAddition.Ergebnis); end; |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Zitat:
Somit entsteht in dem Form 0 Code. Es gibt nur ca 4 Zeilen externen Wire up Code. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Es geht ja gerade darum, die Logik vom GUI zu trennen. Deswegen darf die GUI die Logik nicht kennen. Und die Logik das GUI auch nicht. Dazwischen muss etwas geschaltet werden, das als Vermittler agiert. Also z.B. klassisches MVC: Model (Logik), View (Form), Controller (kennt beides), der Controller fehlt hier komplett und wäre dann das, was die Logik-Klasse mit ihren Properties an die ein- bzw. Ausgabefelder am Form und die Ausführung der Methode an deren Button event bindet. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Ich mache das immer der Art:
Delphi-Quellcode:
Konkrete Implementation der visuellen Repräsentation im Presenter/in der View (ich verwende eine abgewandelte Form des MVC):
type
TAdditionVisualComponent = class public: procedure resultChangeEvent(result: integer); virtual; abstract; end; type TAddition = class [...] private: visualComponent: TAdditionVisualComponent; end; // --- function TAddition.Addition(Zahl1, Zahl2: Integer): Integer; begin [...] if self.visualComponent <> nil then self.visualComponent.resultChangeEvent(Zahl1 + Zahl2); end;
Delphi-Quellcode:
Der Aufruf des ganzen erfolgt aus der GUI über den Controller (falls vorhanden zuvor über den Presenter):
type
TAdditionVC = class(TAdditionVisualComponent); public: procedure resultChangeEvent(result: integer); override; end; // --- procedure TAdditionVC.resultChangeEvent(result: integer); begin Form1.Edit1.Text = IntToStr(result); end;
Delphi-Quellcode:
Jetzt kommt es darauf an, wie man den Controller mit den Business-Objekten verbinden möchte.
MyController.Add(StrToInt(Edit2.Text), StrToInt(Edit3.Text));
Der einfachste Fall (der Controller kennt nur ein Objekt):
Delphi-Quellcode:
Das ist das, was ich aus dem Stehgreif auf die Schnelle zusammentragen kann.
type
Controller = class; private: MyAddition: TAddition; end; // --- procedure Controller.Add(Zahl1, Zahl2: integer); begin MyAddition.Addition(Zahl1, Zahl2); end; MyAddition |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Das ist auch ansatzweise an deinem Beispiel sichtbar. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
"Wie mache ich aus einer trivialen Aufgabe ein extrem kompliziertes Konstrukt"
So wäre meine Kurzbeschreibung zu dem, was ich bisher hier im Thema gelesen habe :-D Aber soll jeder machen, wie er's für richtig hält :P |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Könnte noch sehr interessant werden, vor allem dann mit X-Plattform. Da bezahlt man dann sehr teuer, wenn man es nicht schön getrennt hat ;) |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Dass man dann mit dem "Ach, bei so nem trivialen Beispiel..." kommen kann, war klar ;) |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Bei großen Projekten wirkt sich das irgendwann nicht mehr so stark aus - und kann auch nicht umgangen werden. Man sollte sich (bei großen Projekten) immer die Option offen halten, die GUI einfach auszutauschen (durch HTML-Oberfläche) oder zu erweitern (unterschiedliche Anzeigen gleichzeitig - sinnvoll: keine Ahnung; möglich: ja). Mich stört beim "klassischen MVC", wie man es im WWW an jeder Ecke erklärt bekommt, dass die Trennung zwischen GUI und Model nicht stark genug ist (vor allem die Richtung View --> Model). Beipsiel (durchgezogener unterer Pfeil):  http://de.wikipedia.org/wiki/Model_View_ControllerZusätzlich verwende ich immer einen Presenter zwischen View (GUI) und Controller, denn es gibt Code, der weder in den Controller noch in die View (Formularcode) gehört. Weiterer Vorteil: mein Controller muss die konkrete GUI (oder deren Anzahl) nicht kennen. --- Was ich für wichtig und keine leichte Aufgabe halte, ist die richtige Positionierung der "echten Verbindungen". Es muss ja eine bidirektionale Verbindung aufgebaut werden (View <--> Model). - Wer kennt wen ab wann. - Sollen Verbindungen verändert werden (Edit-Feld soll ein den Wert eines anderes Business-Objektes repräsentieren)? |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Der Ruf nach mehr Einfachheit und weniger Schreibarbeit ist aber schon berechtigt.
Ich vereinfache dazu meine Klassen auf das Minimum:
Delphi-Quellcode:
Wenn diese Hilfsklasse sowieso nur im Kontext des Formulars benützt wird, wozu dann diese schreibträchtigen Properties einbauen?
type
TCalculator = class public procedure Addition; procedure Subtraktion; Zahl1: Integer; Zahl2: Integer; Ergebnis: Integer; end; Im Gegenzug scheue ich mich aber auch nicht, relativ kleine und einfache (Hilfs-)Klassen in meinem Formular zu benützen. Ich ersetze Properties durch public Variablen aber nur dann, wenn ich mir sicher bin, dass ich die Klasse nur hier an Ort und Stelle benötige. Klassen, die weiter ins Programm reichen werden weiterhin "anständig" programmiert. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Für diesen einfachen Fall zu umständlich.
Delphi-Quellcode:
Result zeigt dann ob was sinnloses gemacht wurde oder kann auf einen Konvertierungsfehler hinweisen.
type
TAddition = class private public function Add(wert1,wert2:integer; var Ergebnis:integer):boolean; end; Implemaentation Function Taddition.Add; begin Ergebnis:=wert1+wert2; result:=(wert1<>0) and (wert2<>0); end; Die Sache mit privaten Feldern, Methoden sowie Properties macht nur dann Sinn, wenn man Werte zwischenspeichen will. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Weiss nich, mit MVC hab ich mich noch nie beschäftigt.
Ich würde einfach dafür sorgen, das mein Formular nur den Code (Logik, Bedingungen etc.) enthält, der für die GUI erforderlich ist (Prototyping). Die Funktionalität erfolgt komplett in eigenen Klassen. Ziel ist es, das jede GUI-Aktion mit genau einem Methodenaufruf abgebildet werden kann. Bisher habe ich sehr selten einen Fall gehabt, bei dem die Funktionsklassen zwischendurch der GUI Bescheid geben müssen, außer vielleicht bei einem Fortschrittsbalken. Wenn das der Fall sein sollte, arbeite ich mit dem Vistor-Pattern, Callbacks oder Notification-Events (meistens Letzteres). Und wenn ich faul bin (oder mit Threads arbeite) gerne auch mit Windows-Messages. Dann läuft die Anwendung zwar nie unter Linux, aber WTF. Es ist etwas altbacken und pragmatisch, aber schlußendlich das Resultat jahrzehntelangen Programmierens mit dem Zweck des einigermaßen effektiven Geldverdienens auf freiberuflicher Basis. Da ich große Unternehmen zufrieden gestellt habe, kann es so falsch nicht gewesen sein. Der große Künstler bin ich nicht, aber dafür bin ich sehr schnell und meine Anwendungen sind mittlerweile sehr robust und leicht wartbar. Da ich zudem die für mich wichtigsten Gedanken vom 'Clean Code' verfolge, bin ich eigentlich mit meinem Gegurke zufrieden. Wenn ich mich mal dabei ertappe, rumzufrickeln, schlägt mir das spätestens bei der ersten fundamentalen Anforderungsänderung gnadenlos ins Gesicht. Zitat:
data transfer objects', sonst nicht. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Dann hast du aber die Aufgabe nicht gelöst, um die es hier geht. Allgemein: Eine saubere Trennung erreicht man nur durch Abstraktion. Dass diese Mehraufwand beim Schreiben verursacht, sollte hier nicht das Thema sein. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Na ja, Getter und Setter sind schon sinnvoll. Dann kann man bei einer Division prüfen, ob nicht der Divisor 0 ist und entsprechend eine Exception werfen. Gut könnte man jetzt auch bei der Division machen. Aber das ist ja sowieso nur hypothetischer Code und es geht ja eigentlich um die Bindung der Klasse an die GUI.
@SebE: Wie würdest du denn das lösen? Bringt doch mal konkrete Lösungsvorschläge. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
@Luckie:
Das steht doch in meinem ersten Beitrag auf Seite 1. Ich mache eben aus 4 Zeilen Quellcode ~80 und verteile die dann auf 3 bis 4 Dateien. Klingt schrecklich, aber wenn man ein Beispiel mit 500 Zeilen nimmt, wird der Overhead auch nicht mehr. Bei dem wirklich winzigen Ausgangsprogramm würde ich auch dringlichst von MVC und Co abraten, da absolut überdimensioniert. Aber wir wollen hier ja das Grundproblem im Allgemeinen lösen. Wenn ich kurz abschweifen darf: Wie würdet ihr folgendes lösen (Trennung spielt eine Rolle)? Ihr habt eine Liste von gleichartigen Elementen, welche dynamisch erstellt werden und durch anklicken von Listeneinträgen (welche die Elemente für den User repräsentieren) ausgewählt werden. Dabei werden die Attribute der Elemente in visuellen Komponenten angezeigt (Edit, Combos, ...). Also: beliebig mehrere Business-Objekte und nur eine Ein-/Ausgabe-Maske. Welche zentrale Einheit übernimmt die Steuerung, was wann angezeigt wird. EDIT: Vielleicht kann man sich vorstellen, dass wir das Ausgangsprogramm durch weitere Operationen (welche in der genannten Liste stehen) erweitern. Wir haben sozusagen 4 Objekte (TAdditio, TSubtraction, TMultiplication, TDivision) aber nur 3 Edit-Felder. Wir benötigen den Button nicht, da durch das Klicken in die Liste das Ergebnis sofort erechnet werden kann. PS: "Sauber" in meinen Augen, wäre eine Lösung, welche den Operationslisten-SelectIndex nicht abfragt. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Ja, dass ist eine gute Lösung.
Ich kenne diese aus C# in Verbindung mit WPF. Geht das auch nativ? Ich bin leider schon einige Zeit aus Delphi raus. Falls nicht: Hast du dennoch eine "hand-made-Lösung"? |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Liste der Anhänge anzeigen (Anzahl: 1)
Nativ wie gesagt mit meiner Library ab Delphi 2010. Das Prinzip dahinter ist aber genauso mit Delphi 7 realisierbar (halt mit einigen Abstrichen bzgl der RTTI und Generics z.B.)
Eingangsbeispiel mal mit meinen DataBindings realisiert im Anhang |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Ob die Klasse jetzt trivial ist oder nicht sollte egal sein. Mir geht es einfach um die perfekte Trennung zwischen GUI und Logik und dafür sollte eine solche einfache Klasse doch ausreichen, oder brauchen wir ein "größeres" Beispiel.
Die Antworten zu dem Thema zeigen mir aber auch, dass es anscheinend nicht so einfach zu sein scheint bzw. die Herangehensweisen stark auseinander gehen. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
@Stevie: In deinem Beispiel fehlt DSharp... Ist das deine Binding-Lösung? Wo kann ich mir die Unit runterladen?
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
@Stevie:
Die Trennung ist wirklich stark, da diese komplett von der "Framework-Magic" übernommen wird. Meine Lösung entspricht weitgehend meiner Lösung auf Seite 1 mit dem Zusatz:
Delphi-Quellcode:
TAddition, TSubtraction, ... sind von TOperation abgeleitet.
procedure List.SelectIndexChange(...);
begin TOperation(Form1.List1.SelectedItem).SetVisualComponent(MyVisualAttributes); end; // --- type TVisualAttributes = class op1, op2: TEdit; result: TEdit; [...] end; In TOperation.SetVisualComponent(vc) wird die visuelle Komponente im Business-Objekt ersetzt und es werden alle ChangeEvents aufgerufen:
Delphi-Quellcode:
procedure TOperation.SetVisualComponent(vc: TVC);
begin self.visualComponent := vc; if vc <> nil then begin resultChangeEvent(...); // hier muss man sich überlegen, // ob die Werte (Zahl1, Zahl2) vorhanden sind bzw. sein sollen. // Sonst: nach SetVisualComponent // TOperation(Form1.List1.SelectedItem).Execute aufrufen end; end; |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
In C# würde man die Bindings mit XAML herstellen. Mir persönlich geht das aber zu weit - ich möchte im Code nachvollziehen können, was wann wo verbunden wird. Das "schlimmste" ist in meinen Augen, dass man Methoden, Objekte (analog Properties) mit Zeichenketten ausweist.
Delphi-Quellcode:
TBinding.Create(add, 'Zahl1', MainForm.edNumber1, 'Text');
Delphi-Quellcode:
Es werden die Elemente der Programmiersprache nicht mehr als Symbole vestanden bzw. angesprochen.
DoPropertyChanged('Ergebnis');
Kann ich mich nicht mit anfreunden. Aber die Idee dahinter finde ich super. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
property references.Übrigens auch in .Net wird mit strings gearbeitet. Der Pluspunkt gegenüber der Delphi Lösung ist halt, dass das XAML auch geprüft wird. Aber wenn du beim NotifyPropertyChanged deine Property falsch schreibst, biste genauso gekniffen (außer du nutzt Prism, wo das durch das keyword notify geregelt wird :love:) |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Wenn Du das im Code machst, produzierst Du zum einen wieder viel mehr Code (der neue Fehler enthalten kann), zum anderen verlierst Du genau die Flexibilität, die solche Binding-Mechanismen gerade erlauben sollen. Der Trick ist doch genau der, Elemente austauschen zu können, die nichts voneinander wissen. Code muss zwangsläufig auf beiden Seiten die Details kennen, um sie aneinander zu koppeln. Deklaratives binding hingegen erlaubt es Dir, sowohl die View als auch das Model auszutauschen, ohne dass es hier zu einer Code-Änderung an irgend einer anderen Stelle kommen muss. Das ist ja auch genau das Problem an MVC: Der Controller muss View und Model kennen, um sie aneinander zu docken. MVVM-Patterns hingegen abstrahieren selbst das Model (reine Business-Logik) noch einmal mit UI-Logik (Erlaubte Aktionen, Dargestellte Werte etc.), und nur die View bindet sich deklarativ ans ViewModel. Deswegen funktioniert auch sowas wie das hier: http://jsfiddle.net/rniemeyer/aDahT/ mit so ungeheuer wenig Code. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
OOP bis zum "Gehtnichtmehr"! Delphi ist für mich ein RAD-Tool und OOP ist kein Dogma. Es gibt nun einfach Dinge, die im praktischen Entwickleralltag sinnlos sind. Eine strikte Trennung von GUI und Anwendungslogik ist in Delphi nicht immer zwingend und verhindert manchmal sogar die Übersichtlichkeit und Lesbarkeit des Codes bei kleinen Projekten. Leider habe ich den Link nicht mehr gefunden, aber irgendwer hat mal ein Horrorbeispiel in OOP für ein Hello-Word Programm geschrieben (vielleicht kennt ja hier jemand das Beispiel). Also meine Ansatz: Auslagerung in externe Klassen nur dann wenn es Sinn macht und/oder die Lesbarkeit des Codes verbessert.
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Das stimmt, aber um so größer und komplexer ein Projekt werden wird, um so wichtiger wird eine Trennung.
Es ist eine Frage des Frameworks, wie komfortabel die Bindung der beiden Ebenen realisiert werden kann. Die Erstellung der Datenebene und der GUI-Ebene für sich sollte jeweils einfacher und übersichtlicher werden. |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Punkt 1: stimmt absolut. Punkt 2: Ich weiß gerade nicht, was ich von Hand nicht machen könnte, was mir Bindings erlauben. Zitat:
Beim Binding muss man angeben, welche Property verwendet werden soll. Ich mache das mit Abstraktionen, die das - und nur das - enthalten, was der Benutzer der konkreten Implementierung wissen darf. Schnittstellen muss man immer angeben. Klar ist es mehr Aufwand, aber so viel auch wieder nicht: nach dem Anpassen der Schnittstelle, die richtigen Objekte erzeugen. Vorteil: der Compiler sagt mir, wenn ich falsche Informationen beziehen möchte. Zitat:
Dass der Controller das Model kennen muss, ist eigentlich kein Problem (meine Controller rufen nur Model-Methoden auf). Für den markierten Teil wird ein Presenter eingefügt, von dem der Controller auch nur die Abstraktion kennt. Meine Architektur: Model: klar! Controller: wählt zu Beginn den Presenter/die View aus; bestimmt, was die Anwendung kann; leitet Anweisungen an Model Presenter: UI-Logik (Weiterleiten von Eingaben); Formatierung der Ausgabe ;Erzeugen von UI-Objekten auf Anfrage des Controllers (auf Anfrage des Models) View: Leitet Eingabe-Events an den Presenter weiter; sieht trollig aus |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Memory Leaks gibt's auch: --------------------------- Unexpected Memory Leak --------------------------- An unexpected memory leak has occurred. The unexpected small block leaks are: 1 - 12 bytes: Unknown x 1 21 - 28 bytes: TList<System.TMethod> x 1 29 - 36 bytes: TEventHandlerInstance x 1 45 - 52 bytes: TEventHandler<DSharp.Bindings.TPropertyChangedEven t> x 1 69 - 76 bytes: TNotificationHandler<TEventHandler<DSharp.Bindings .TPropertyChangedEvent>> x 1 The sizes of unexpected leaked medium and large blocks are: 52012 --------------------------- OK --------------------------- |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Der Thread heißt "Trennung von GUI und Logik". Wenn du uns zeigen kannst, wie man ohne Vererbung diese gewünschte Trennung vollziehen kann, bin ich sofort ruhig. Bis dahin sage ich: Wieder am Thema vorbei. Was nützt es dem TE, wenn er es wissen will, oder wirklich benötigt? Ein Problem wegzureden, löst es nicht. Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Also ich will es unbedingt wissen und benötigen wird man es so oder so... :mrgreen:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
|
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
- Nativ ohne Framework-Einsatz (mein Code sollte einen Einblick gegeben haben, wo die Knackpunkte liegen) - "magische Lösung", bei der vieles versteckt wird und das Projekt schön klein bleibt. Wenn du es unbedingt (aus Bildungsgründen) zu Fuß machen möchtest, schaue dir folgende Pattern an: Observer, Visitor, Proxy |
AW: Trennung von GUI und Logik, wie geht ihr vor?
Zitat:
Ich programmiere seit über 25 Jahren und bin der Meinung, dass hier extremst ubers Ziel hinausgeschossen wird. Das riecht verdammt nach OOP-Fetischismus *gg* |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 18:15 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