Trennung von GUI und Logik, wie geht ihr vor?

[SebE]

Zitat von Luckie:

Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.

(fett durch mich)

Im Allgemeinen gilt: je mehr Abstraktionen, desto flexibler die Anwendung (die Kommunikation).
Ob der Code dabei übersichtlich bleibt, ist fraglich.
Man kann auch Abstraktionen einführen, die wenig Sinn ergeben oder einfach nicht hilfreich sind.

Klar hat man irgendwo Bindungen. Diese sollten aber - wenn möglich - an "festen" Ort (Controller) plaziert werden und nicht dort, wo am ehesten Änderungen stattfinden (GUI, gefolgt vom Model).

Ein Muss ist auf jeden Fall, eine Abstraktion der GUI aus Sicht des Models, dieses darf die View nicht kennen.
Anders herum ist es vllt nicht immer notwendig, aber "schöner", wenn man eine zusätzliche Schicht hat (Controller).
Denken wir einmal an die Überarbeitung (Refactoring) unserer Business-Objekte (Schnittstellen "verschönern"): Hier wäre es gut, wenn man die GUI belassen kann, wie sie ist.

@Hansa:
Sorry, ich habe deinen Beitrag leider nicht verstanden (ich erkenne an deinem Code-Schnipsel weder OOP, noch wird mir eine Art Ironie ersichtlich).
Ich erkenne nur, dass hier nicht getrennt werden wollte.