Trennung von GUI und Logik, wie geht ihr vor?

[Progman]

"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
Aber soll jeder machen, wie er's für richtig hält

[Florian Hämmerle]

Zitat von Progman:

"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
Aber soll jeder machen, wie er's für richtig hält

So wie ich es verstanden habe, möchte der TE an einem einfachen Beispiel die Herangehensweise erlernen. Da bringt es nichts, gleich komplexe Beispiele zu bringen. Lieber vom kleinen dann aufs große übertragen
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

[Stevie]

Zitat von Progman:

"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
Aber soll jeder machen, wie er's für richtig hält

Wie gut, dass er uns hier ein einfaches Beispiel gegeben hat und nicht eine komplette Warenwirtschaft und dann gefragt hat, hey, zeigt mir das mal ...

Dass man dann mit dem "Ach, bei so nem trivialen Beispiel..." kommen kann, war klar

[shmia]

Der Ruf nach mehr Einfachheit und weniger Schreibarbeit ist aber schon berechtigt.
Ich vereinfache dazu meine Klassen auf das Minimum:

Delphi-Quellcode:

type
  TCalculator = class
  public
    procedure Addition;
    procedure Subtraktion;
    Zahl1: Integer;
    Zahl2: Integer;
    Ergebnis: Integer;
  end;

Wenn diese Hilfsklasse sowieso nur im Kontext des Formulars benützt wird, wozu dann diese schreibträchtigen Properties einbauen?
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.

[Luckie]

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.

[SebE]

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

[Stevie]

Zitat von SebE:

Wenn ich kurz abschweifen darf:
Wie würdet ihr folgendes lösen (ob mit/ohne Trennung spielt erst einmal keine 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, ...).

Die Properties des SelectedItem des Listen Controls an die anderen Controls binden. (siehe VirtualTreeviewSample oder Sample5 in meinem svn Repository)

Zitat von SebE:

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.

Entweder die entsprechenden Rechen routinen auf die Listen Items binden oder ein Objekt haben mit den 4 Operationen, welche abhängig vom ausgewählten Operator durchgeführt werden (das wär dann eher die ComboBox + Button Lösung)

[SebE]

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"?