Der verständlich Drang, Ordnung is Chaos einer TForm-
Unit zu bringen, ist verständlich.
Aber wenn man Frames nähme, würden sich die Probleme hier gar nicht so stark äußern, denn dann hätte man auch in der UI das SRP weitestgehend abgebildet: Jeder einzelne Frame wäre dann so übersichtlich, das man auf eine logische Gruppierung der vielleicht 5-10 Events verzichten könnte, zudem die
IDE einem sehr komfortable Navigationshilfen bietet.
Jedenfalls wäre ein TForm-Ungetüm in der Art
Delphi-Quellcode:
TYPE
TFormMain = CLASS(TForm)
AktionsListe : TActionList;
...
// gefühlte 100 Zeilen später
end;
per se aufgeräumter (Deklaration und Code)
Delphi-Quellcode:
TYPE
TFormMain = CLASS(TForm)
Aktion : TActionFrame;
HauptMenu : TMenuFrame;
Buttons : TButtonFrame;
Staaten : TStaatenFrame;
Waehrungen : TWaehrungenFrame;
StatBarMain : TJvStatusBar;
...
end;
Auch werden hier kaum noch Events bedient (außer die der Form, versteht sich). Und ob man da denn nun wirklich die alphabetische Reihenfolge *benötigt*, sei mal dahingestellt, obwohl der Codeformatter einem das ja anständig aufräumt.
Eine aufgeräumte UI geht aber nur bei aufgeräumtem Model (Klassen), womit es folgerichtig fast unmöglich ist, seinen Spaghetticode nachträglich so aufzuräumen, Andererseits ist es aber sehr praktisch: Fängt man an, sich zu zwingen, die UI in einzelne Komponenten/Frames nach dem SRP-Prinzip zu unterteilen, landet man zwangsläufig bei aufgeräumtem Code. Man kotzt so lange rum, bis alles irgendwie passt, und man bei etwas Ähnlichem wie MVVM landet. Man kann ja nicht aus einem Frame einfach die Funktion eines anderen Frames aufrufen, denn die kennen sich ja nicht mehr: Im Gegensatz zum Spaghetti-Form, wo
Menu_fooBar
durchaus
Lbl_Schießmichtot
kennt.
Frame A kennt nur das VM, aber Frame B auch und wenn nun A im VM rumändert, kann das VM dies über ein Notify-Event publizieren und Frame B kann sich entsprechend updaten.
Allerdings verlässt man dann das R vom
RAD (Rapid Application Development) und arbeitet eher im SACADWALOC (Slow and Clean Application Development with a lot of Code) Bereich. Vorteil ist dann aber, das die Maintenance, Skalierbarkeit und Erweiterbarkeit wesentlich nachhaltiger ist. Aber das Wichtigste ist (meine Erfahrung): Beim MVVM verstehen auch andere Programmierer, was man meint.