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.