Ich habe gerade folgendes gefunden und gemerkt, dass mein Verständnis von MVC doch sehr lückenhaft war:
http://codebetter.com/jeremymiller/2...e-of-contents/
Mit dieser sehr guten Erklärung muss ich folgendes zu meiner Umsetzung sagen:
Ich habe nicht vor in die 3 MVC-Teile zu splitten, sondern nur in 2 - View und Controller sind in meinen TView-Descendents zusammengefasst. Model ist meine Logik. Mein Loader ist tatsächlich nur zum Instanzieren gedacht und macht sonst nichts weiter.
Es handelt sich bei dem Programm um eine Eigenentwicklung mit ausschließlicher in-House Verwendung. TMain muss Basisfunktionalität und eine Auswahl von aktuellen Projekten bereitstellen. Die Projekte werden eine gemeinsame Basis und dann immer wieder neu zu programmierende Inhalte haben. Die Programmierung dieser Projektinhalte muss in kürzester Zeit möglich sein. Änderungen an bestehenden Teilen sind fast ausschließlich Änderungen an der Funktion, die ggf. bis zur UI durchschlagen. Es wird aber z.B. keine Änderung der UI ohne neue Funktionalität geben. Mit ganz viel Vorausschau und Phantasie könnte es vielleicht irgendwann eine Weboberfläche geben. Dann müsste der Controller-Teil sowieso mit erneuert werden.
Der Vorteil, den ich mir durch die Trennung verspreche, ist, dass das Design der Logik unabhängig von der UI erfolgen kann. Somit bin ich bei der Strukturierung der Logik nicht mehr an die Aufteilung in Fenster und Frames gebunden. Wenn Informationen aus mehreren logischen Bestandteilen benötigt werden, werden eben mehrere Logikbausteine an eine View übergeben.
Wenn der Controller auf bestimmte Ereignisse der Logik oder der UI reagieren soll, dann kann man das (wie der Name schon sagt) über entsprechende Events oder ein Observer Pattern lösen. Oder man gibt entsprechende Callback-Interfaces an die Logik bzw. die UI. Damit bleibt die Trennung weiterhin erhalten bzw. das gegenseitige "Kennen" wird auf das notwendigste Minimum (Events, Interfaces) beschränkt.
Bevor ich jetzt noch einen Umweg mehr einbaue (Interfaces/Events) und damit den Aufwand weiter erhöhe, ist in meinem Fall wohl eine Referenz weniger kritisch.
Wäre es nicht besser statt einer abstrakten Klasse ein oder mehrere voneinander abgeleitete Interfaces zu nehmen?
Sonst kommt man irgendwann doch noch dazu, in der abstrakten Klasse Code zu implementieren.
Durch ein Interface sagst du nur, was für ein Verhalten die zu erstellende Klasse können muss.
Der Vorteil von Interfaces gegenüber abstrakten Klassen liegt m.E. in der Referenzzählung und dass eine Klasse mehrere Interfaces implementieren kann. Beides brauche ich nicht. Da die abstrakte Klasse direkt zur konkreten Implementierung gehört, brauche ich gar nicht auf den Gedanken zu kommen in der abstrakten Klasse etwas implementieren zu wollen. Das kann in jedem Fall in der konkreten Ableitung passieren.
Ich denke ich werde es so machen wie in meinem vorherigen Post beschrieben. Falls jemand erkennt, dass ich mir mit dem beschriebenen Design entscheidende Probleme einbaue, dann bitte ich darum, mich darauf aufmerksam zu machen.
"Seit er seinen neuen Computer hat, löst er alle seine Probleme, die er vorher nicht hatte."