Naja meine Eventbeispiele waren nicht so dolle
Sollten nur dumme Beispiele sein. Das ganze System dahinter habe ich aus mehreren Büchern zusammengesetzt. Zum Teil wird es mal mit irgendwelchen Nachrichten gelöst und zum Teil halt mal über Events. Die Codes dazu waren bis jetzt immer in C++ weshalb ich noch garnicht drüber nachgedacht habe da mit den C# eigenen Events zu arbeiten. Aber darum gehts auch erstmal nicht
Der EventManager macht für mich insofern Sinn, als dass ich dadurch eine gut erweiterbare Basis besitze. Dazu aber gleich mehr. Wenn ich zum Beispiel eine Viewklasse habe, sollte diese natürlich auf so gut wie alles reagieren. Zum Beispiel würde bei einem Schuss ein Sound abgespielt. Dazu vielleicht noch ein Partikelsystem. Zusätzlich müsste bei dem Event natürlich ein Objekt für den Schuss erzeugt werden. Wären 2 kleine Beispiele für Klassen die es interessieren würde über so etwas informiert zu werden. Wenn ich jetzt den Methodenaufruf direkt einbaue, dann müsste bei jedem Schuss jede Klasse informiert werden, die sich dafür interessieren könnte. Das könnte man dann natürlich über einen einfachen Observer regeln, dafür müsste dann jedoch jede Klasse die sich dafür interessiert die Klasse kennen, die den Schuss auslöst. Da diese Klassen sich natürlich für mehrere "Events" interessieren wären dadurch unschöne Abhängigkeiten drin. Vorallem eine Viewklasse müsste zu viel über andere Klassen wissen. Der weitere Vorteil ist, dass wenn die Steuerung etc über diese "Events" geregelt wird, eine Netzwerkkomponente relativ einfach zu implementieren ist. Ob ein Event nun von einer lokalen Komponente oder aus dem Netzwerk kommt, ist ja erstmal völlig egal. Zusätzlich habe ich dann durch die Queue im Eventmanager den Vorteil, dass nicht jedes Event direkt gesendet werden muss, sondern einmal pro Zyklus die alles gepackt werden kann und gesendet wird. Der Eventmanager bietet zusätzlich eine Schnittstelle, um alle Events und somit den gesamten Workflow zu loggen, was meiner Meinung nach auch sehr von Vorteil ist. Für mich sind die Vorteile von einer Schnittstelle für die Events doch recht klar. Lasse mich aber auch gerne von anderem Überzeugen.
Also vom Prinzip:
Objekt sendet Event an EventManager.
EventManager löst einmal pro Zyklus alle enthaltenen Events aus und benachrichtigt für jedes Event die registrierten Eventlistener.
Die Eventlistener verarbeiten die Events weiter und reichen sie an die untergeordneten Objekte weiter.
Meiner Meinung nach ein sehr lose gekoppeltes System, mit großem Potential zur Erweiterung. Das sollte das meiste geklärt haben.