Trennung von GUI und Logik, wie geht ihr vor?

[stahli]

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.

[SebE]

Zitat von Phoenix:

Aber genau darum geht das doch das entkoppeln. Das es eben genau nicht mehr im Code steht sondern lediglich noch Deklarativ geschieht.

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.

(fett durch mich)
Punkt 1: stimmt absolut.
Punkt 2: Ich weiß gerade nicht, was ich von Hand nicht machen könnte, was mir Bindings erlauben.

Zitat von Phoenix:

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.

Beim Verbinden muss immer Information offen gelegt werden.
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 von Phoenix:

Das ist ja auch genau das Problem an MVC: Der Controller muss View und Model kennen, um sie aneinander zu docken.

(fett durch mich)

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

[divBy0]

Zitat von Stevie:

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

Das Beispiel funktioniert bei mir aber nicht. Der Button löst keine Addition aus.

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

[Stevie]

Zitat von bernerbaer:

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.

Wer schonmal an einem Projekt gearbeitet hat, wo trotz Mockups plötzlich die Entscheider der Meinung war, dass der Workflow für den Benutzer ja so mal garnicht geht und man das ganze doch ganz anders bedienen und darstellen muss, wird geflucht haben, wenn er dann überall in irgendwelchen Control Events rumfrickeln durfte, um das alles anzupassen, wenn er nicht strikt getrennt hat.

[SebE]

Zitat von bernerbaer:

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.

(fett von mir)

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:

OOP bis zum "Gehtnichtmehr"!

Ein Muss, wenn du mit C# programmierst!

[Stevie]

Zitat von divBy0:

Zitat von Stevie:

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

Das Beispiel funktioniert bei mir aber nicht. Der Button löst keine Addition aus.

Memory Leaks gibt's auch

Liegt wohl daran, dass im svn nicht die aktuellste version liegt, ich bin gerade dabei neuste Änderungen einzuchecken. Dazu gehört u.a. ActionBinding. Versuchs später oder morgen früh nochmal.

Zitat von bernerbaer:

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.

Nicht böse gemeint, aber du gehörst scheinbar auch zu der Sorte Delphi Entwickler, die meint, nur weil man Buttons, Edits und Listboxen aufs Form streuen kann und mitm Doppelklick die nötige Logik ins Event klimpern kann, muss man das auch so machen und alles andere wäre dogmatisch. Natürlich kann man auch nen Hello World Programm over engineeren, aber genau dafür sind nunmal simple Beispiele da. Wer's an sowas nicht lernt, dem brauchste garkein echten Usecase geben.

[divBy0]

Also ich will es unbedingt wissen und benötigen wird man es so oder so...

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

[SebE]

Zitat:

Also ich will es unbedingt wissen und benötigen wird man es so oder so...

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

[Progman]

Zitat von Stevie:

Wer schonmal an einem Projekt gearbeitet hat, wo trotz Mockups plötzlich die Entscheider der Meinung war, dass der Workflow für den Benutzer ja so mal garnicht geht und man das ganze doch ganz anders bedienen und darstellen muss, wird geflucht haben, wenn er dann überall in irgendwelchen Control Events rumfrickeln durfte, um das alles anzupassen, wenn er nicht strikt getrennt hat.

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*