Trennung von GUI und Logik, wie geht ihr vor?

[bernerbaer]

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. Eine Trennung von GUI und Logik ist in diesem Mini-Beispiel definitiv nicht machbar. Zahl1 und Zahl2 sind zwingend mit der Form verbunden. D.h. benötige ich wie im Beispiel nur die Addition, weshalb soll ich eine Abstraktionsebene aufbauen in einem einzubindenden externen Objekt? Wo liegen hier die Vorteile der Trennung (nur in diesem Beispiel? Vererbung - was soll vererbt werden? Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Nein, ich gehöre nicht zu den Programmierern die einfach Buttons und Edits auf die Form klatschen! Ich bin ein Programmierer der sich überlegt was er macht und den Aufwand und Ertrag abschätzt. Wo Trennung von GUI und Anwendungslogik sinn macht, setze ich es auch ein. Aber ich bin nicht ein Gläubiger der macht, was die Mehrheit sagt.

[SebE]

Zitat von bernerbaer:

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. Eine Trennung von GUI und Logik ist in diesem Mini-Beispiel definitiv nicht machbar. Zahl1 und Zahl2 sind zwingend mit der Form verbunden. D.h. benötige ich wie im Beispiel nur die Addition, weshalb soll ich eine Abstraktionsebene aufbauen in einem einzubindenden externen Objekt? Wo liegen hier die Vorteile der Trennung (nur in diesem Beispiel? Vererbung - was soll vererbt werden? Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Darum geht es dem TE doch garnicht.
Er hätte auch ein beliebig größeres Beispiel wählen können.
Hater er aber nicht - damit müssen wir uns abfinden und nicht darauf rumreiten, dass es wenig Sinn ergibt.
Ich denke, je kleiner das Beispiel, desto einfacher kann man ein Verständnis für die Grundlagen erlangen.
Bei größeren Beispielen treten wieder Sonderfälle auf (ich habe selbst welche erwähnt), die vom Grundproblem ablenken und den Lernprozess behinern.

[divBy0]

Ihr dürft gerne auch ein umfangreicheres Beispiel posten...

[Stevie]

Zitat von bernerbaer:

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. Eine Trennung von GUI und Logik ist in diesem Mini-Beispiel definitiv nicht machbar. Zahl1 und Zahl2 sind zwingend mit der Form verbunden. D.h. benötige ich wie im Beispiel nur die Addition, weshalb soll ich eine Abstraktionsebene aufbauen in einem einzubindenden externen Objekt? Wo liegen hier die Vorteile der Trennung (nur in diesem Beispiel? Vererbung - was soll vererbt werden? Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Nein, ich gehöre nicht zu den Programmierern die einfach Buttons und Edits auf die Form klatschen! Ich bin ein Programmierer der sich überlegt was er macht und den Aufwand und Ertrag abschätzt. Wo Trennung von GUI und Anwendungslogik sinn macht, setze ich es auch ein. Aber ich bin nicht ein Gläubiger der macht, was die Mehrheit sagt.

Seit wann sind 2 Zahlen für eine Addition mit einem Form verbunden? Schreib mal die App um, damit eine Konsolenanwendung draus wird. Jaja, bei dem Additionsbeispiel isses Killefit. Aber ich kanns auch noch gern zum xten mal sagen, es ging bei diesem Beispiel um die Ansätze und nicht darum, ob es Sinn ergibt.

Copy und Paste verletzt schonmal eine der grundlegendsten Regeln ("don't repeat yourself"), an die ich mich persönlich versuche zu halten (klappt auch nicht immer )

[Chemiker]

Hallo,

ich finde das Thema sehr interessant. Das Beispiel ist auch OK.

Ich versuche diese Trennung, wenn möglich auch immer hinzubekommen. Meine Erfahrung ist aber leider, wenn die GUI erweitert werden soll müssen die Daten ja in der Regel bis zur Business-Logik durchgereicht werden. Wenn wir bei dem Beispiel bleiben währe die Erweiterung der GUI um eine Edit-Komponente die eine 3 Zahl aufnimmt für die Berechnungen.

Bis bald Chemiker

[bernerbaer]

Zitat von Stevie:

Seit wann sind 2 Zahlen für eine Addition mit einem Form verbunden?

Siehe Ausgangspost:

Delphi-Quellcode:

..
type
  TForm1 = class(TForm)
    EditZahl1: TEdit;
    EditZahl2: TEdit;
...

und so würde das Beispiel bei mir aussehen
Pseudocode:

Code:

uses
meineMathUnit;

Resultat:= MeineAdditionsfunktion(zahl1,zahl2)

[SebE]

Zitat von bernerbaer:

Zitat von Stevie:

Seit wann sind 2 Zahlen für eine Addition mit einem Form verbunden?

Siehe Ausgangspost:

Delphi-Quellcode:

..
type
  TForm1 = class(TForm)
    EditZahl1: TEdit;
    EditZahl2: TEdit;
...

Das sind die visuellen Repräsentationen der Zahlen. Die Zahlen selbst sind es nicht (das drückt auch der Typ TEdit aus).
Man kann auch TAddition.Addition(2, 3) aufrufen.

Wie man sieht, gibt es min. zwei Schichten oder Komponenten, die man trennen KANN.

[Stevie]

Habt ihr übrigens gemerkt, dass die Binding Lösung auch die Typen Konvertierung von String in Int und wieder zurück übernimmt? (mit nem kleinen Fehler im Demo seh ich gerade, negatives Ergebnis wird nicht richtig als signed Integer umgewandelt - fixed)

@divBy0: Beispiel müsste nach einem Update des svn repos nun fehlerfrei und erwartungsgemäß laufen.

[SebE]

Zitat von Stevie:

Habt ihr übrigens gemerkt, dass die Binding Lösung auch die Typen Konvertierung von String in Int und wieder zurück übernimmt?

Du bist lustig!
Wie würde es denn anders funktionieren, besser: wo würde man es denn sonst noch einsetzen können?

Integer werden automatisch zu Zeichenketten, Zeichenketten werden automatisch zu Bezeichnern.
Das geht doch nicht mit rechten Dingen zu

[ehX]

Ist es in der realen Welt nicht oft so, dass sich manche Porgrammierer gegenseitig lobhudeln, weil sie ach so tollen Code geschrieben haben und man auch noch in manchen Foren zerrissen wird, wenn man etwas nicht nach dem höchsten Gut der Programmierkunst programmiert hat, jedoch dann, im Gegensatz dazu, oft Programme mit "miesem" Code jahrelang überleben und erfolgreich sind?

Warum ich das sage: Gutes Codedesign ist zwar generell löblich, jedoch nicht immer der Schlüssel zum Erfolg.
Oft trift sogar das Gegenteil zu: Die in kürzester Zeit hingewurschtelte "Quick'n dirty"-Lösung sichert einem oft genug den nächsten Auftrag vom gleichen Kunden

Ich arbeite derzeit z.B. sehr viel in php mit dem Zend-Framework....mag sein, dass das "gutes" MVC ist..allerdings ist die unübersichtlichkeit aufgrund der MVC_Struktur so extrem, dass die Produktivität m.E. völlig flöten geht und ich das ganze in "bösem" prozeduralen Code oder auch OOP-Code, der nicht so extrem getrennt ist, schon 10x geschrieben hätte und der Kunde nicht so lange warten müsste.


Edit: Das ist nur meine Meinung! Um es nochmal zu verdeutlichen.