Die Eventkatasrophe ist was ganz anderes.

Du kannst das sog. Observer Pattern implementieren. Dabei regestrieren sich klassen an einer anderen und teilen dieser quasi mit, dass sie benachrichtig werden wollen, wenn sich die Eigenschaft XYZ verändert.
Tritt dieser Fall ein, Feuer die Klasse mit dem geänderten Wert ein "ValueChange" (oder wie immer du das nennst) Event zu den registrierten Observern.

Wenn die wiederum eigene Werte ändern wo wieder andere Observer drauf lauschen, kann das schnell ausarten.

Man muss also genau prüfen wen man wo als Observer registriert.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Achso...kk...sowas gibts bei mir nur zweimal....

a) Wenn sich irgendeine Eigenschaft ändert, die allgemein was am Aussehen einer Komponente ändert wird deren übergeordnete Komponente benachrichtigt, dass das eingetreten ist. Geplant ist irgendwann, die GUI-Komponenten in FBO's zu rendern, die solange nicht neu gerendert werden, bis sich eben eine solche visuelle Eigenschaft ändert.

b) Wenn sich die ZOrder einer Komponente ändert, wird die übergeordnete Komponente nochmal gesondert benachrichtigt, weil dann die Reihenfolge, in der die Unterkomponenten gerendert werden müssen (wegen Transparenz und so) u.U. nicht mehr die selbe ist.

Wobei...wenn ich so drüber nachdenke...da werden keine Events ausgelöst...das nächste mal wenn gerendert werden soll, wird einfach überprüft, ob sich was geändert hat...

Das was ich angesprochen hatte mit den Events war evtl. etwas schlecht ausgedrückt (im Allgemeinen kam mein post wohl schlecht rüber, sry an dieser Stelle). Um einem Objekt bescheid zu geben, das sich was geändert hat kann man Events sehr gut benutzen, allerdings bieten sie sich auch an, um an bestimmten Stellen im Verhalten eines Objektes (kann ja auch eine Komponente sein) einzuschreiten und der Komponente zu sagen, sie soll sich anders verhalten als sonst. Das war der worst case, den ich meinte.
Das ist im Prinzip so, als würde Eine Person einer anderen Befehlen etwas zu tun, was sie eigentlich garnicht will. Das sollte man vermeiden.
In deinem Fall ist es völlig legitim Events zu benutzen, da du so das beobachtende Objekt (also dein Manager) einfach bescheid geben kannst, das sich etwas geändert hat und es darauf reagieren muss. Typisch für so was ist OnUnterobjektChange -> SetBeobachter.UnterobjekteNeuBerechnen. Da macht das Sinn und ist auch schnell nachvollziehbar.
Anders ist es wenn man z.B. einen TreeView hat und dem über ein Event sagt, dass er seine Spalten umsortieren muss, sein DragDrop-Event verändert wird und anschließend noch bestimmte Einträge andere Schriftarten haben sollen. Das sind (sagen wir es mal vorsichtig) intime Eigenschaften des TreeViews, über die er selbst entscheiden sollte (das muss man ihm natürlich beibringen, in dem man ihn Ableitet und sein Verhalten entsprechend neu definiert).

_________________
Klar Soweit?