Trennung von GUI und Logik, wie geht ihr vor?

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

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