Trennung von GUI und Logik, wie geht ihr vor?

[SebE]

Zitat von stahli:

Zitat von SebE:

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 meinst Du damit?

Ich bin einfach der Meinung, dass man die Trennung nur durch Abstraktion (also mittels Vererbung) erreichen kann.

[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 Progman:

Aber was ist mit einem solchen "dreiteiligen" (ich nenns mal so) Programmieren, wenn 1 Woche vor Deadline der Entscheider meint, dass auf der Oberfläche noch einige Bedienelemente sein müssen, die dann Fenster erscheinen lassen, wo der User was eingeben/einstellen kann? In der normalen RAD-Programmierung geht das ruckzuck. Nach diesem "Model" müsste ich alle drei Teile erweitern und zusehen, dass ich die auch exakt wieder verbinde. Resultat wäre doch sicherlich ein Code-Chaos, wo man bei eventuell nötigen Änderungen gar nicht mehr durchblickt
Ich programmiere seit über 25 Jahren und bin der Meinung, dass hier extremst ubers Ziel hinausgeschossen wird. Das riecht verdammt nach OOP-Fetischismus *gg*

Das kommt immer auf die konkrete Aufgabenstellung an.
Das Model zu erweitern sollte der gleiche Aufwand sein wie beim RAD.
Neue Verbindungen zu ziehen, sollte dank "Philosophie" (die in einer Dokumentation - falls vorhanden - ersichtlich wäre) "relativ" leicht gehen.
Und am Ende entsteht nicht dieses Durcheinander wie beim RAD.

Man darf es auf beiden Seiten (Pro-OO und Contra-OO) nicht zu sehr verallgemeinern.
Es sind Philosophien, die Vor- und Nachteile mit sich bringen.
Ein Beispiel, was mir einfällt, um das zu verdeutlichen, wäre ein von Hand geschriebener Parser (eines Compilers), der Syntaxregeln folgt.
Sollte man den Parser nach den Durchläufen (Quellsprache Parsen, Zwischensprache generieren, Zielsprache generieren) oder nach den Regeln (If-Statement, For-Statement, Class-Definitio, ...) "ausrichten".

Vorteil der Ausrichtung nach Durchläufen:
Neue Durchläufe können schnell eingebaut werden (zB ein weiterer Optimierungsschritt auf der Zwischensprache).
Vorteil der Ausrichtung nach Regeln:
Neue Sprachkonstrukte können schnell eingebaut werden (zB for-each-Statement).

Wie man sieht, ist alles Situationsabhängig. Man muss eben abwägen.

[divBy0]

Zitat von SebE:

Dann hast du die Wahl: zwei Lösungen wurden vorgestellt (mehr kenne ich auch nicht):
- 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

Ich muss mir die beiden Varianten jetzt mal genauer anschauen. Bei der "magischen Lösung" warte ich erst mal bis das Beispiel funktioniert.

Noch mal, die Addition sollte hier nur ein Beispiel sein. Auch bei diesem Mini-Beispiel sollte eine Trennung möglich sein. In der Praxis sind die Klassen auch um einiges Größer (ca. 25 Parameter und verschiedene komplexe Berechnungen) nur die Klassen darf ich leider hier nicht posten.

Vielen Dank euch allen schon mal für die rege Teilnahme hier. Vielleicht kommen ja noch ein paar interessante Ideen oder Beiträge hinzu. Es würde mich sehr freuen!

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