Kontrollflussarchitektur bei Ereignissen: Geschmackssache?!?

[BrightAngel]

Guten Abend zusammen!

Es gibt ein Thema mit dem ich mich in den Jahren immer wieder intensiv auseinandersetzen musste und mit dem jeder von uns mehrfach täglich Kontakt hat und das wir glaube ich sehr intuitiv benutzen: Den Kontrollfluss von Ereignissen.

Stellt euch ein einfädiges Programm vor. Ereignisse (z.B. onClick) sind zentraler Bestandteil der Programmarchitektur. Insbesondere wird in der gewählten Architektur ein Ereignissystem eingesetzt, das bei einem einzelnen Ereignis mehrere Listener informieren kann (also zum Beispiel ein einzelnes "onClick" dazu, dass mehrere Programmroutinen nacheinander ausgeführt werden).

[Edit]
Nachdem "Der schöne Günther" mir bereits Feedback gegeben hat: Seine Zusammenfassung trifft mein Anliegen sehr gut; wer lieber meine Frage kurz und knapp lesen möchte, den verweise ich gerne einen Post weiter. Wenns um Details geht, bitte hier weiterlesen.
[/Edit]

Jetzt die Frage: Wie soll der Kontrollfluss eurer Meinung nach laufen? Also vorweggenommen: Beide hier vorgestellten Kontrollflussszenarien habe ich so in etwa schon gesehen und haben jeweils ihre Vor- und Nachteile. Ich glaube, dass man mit beiden Kontrollflussmechanismen in der Lage ist, die selben Programme zu schreiben. Es ist nur eine Frage der "Schönheit"

Hier jetzt mal ein Beispielablauf (nur ganz grob):

1. Das Ereignis tritt ein (z.B. Maus Ereignis "click" wird vom Betriebssystem an das Programm weitergereicht)
2. Ereignisverteilungsroutine wird betreten
3. Ein Listener, der zuvor auf dem Ereignis angemeldet wurde wird betreten
4. Dieser Listener löst ein anderes Ereignis aus (z.B. ein synthetisches "change"-Ereignis)

Ab hier unterscheiden sich jetzt die beiden Ereignisarchitekturen.
Kontrollflussbeschreibung "MachsSpäter" (defer):

1. Das Ereignissystem merkt sich das "change"-Ereignis für die spätere Behandlung
2. Es betritt weitere Listener aus dem "click" Ereignis
3. Der Kontrollfluss kehrt aus der "click" Ereignisverteilungsroutine zurück und findet das zuvor gemerkte "change"-Ereignis
4. Das "change"-Ereignis wird analog zum gerade beschriebenen Prozess abgearbeitet (und kann auch weitere synthetische Ereignisse auslösen, die dann wiederrum bis nach dem "change"-Ereignis aufgehoben werden)
5. Ein Äquilibrium wird erreicht; es sind keine weiteren Ereignisse abzuarbeiten.

Kontrollflussbeschreibung "MachsSofort" (immediate):[*]Das Ereignissystem betritt die Ereignisverteilungsroutine des "change"-Ereignisses[*]Die Listener des "change"-Ereignisses werden der Reihe nach abgearbeitet (und dabei können weitere synthetische Ereignisse ausgelöst werden, die dann wiederrum direkt abgearbeitet werden)[*]Der letzte Listener des "change"-Ereignisses wurde abgearbeitet.[*]Die verbliebenen Listener des "click"-Ereignisses werden abgearbeitet. Ereignisbehandlung analog.[*]Der letzte Listener des "click"-Ereignissses wurde abgearbeitet; es ist nichts mehr zu tun.[/LIST]
Ab hier treffen sich beide Möglichkeiten wieder:

1. Es wird wieder auf weitere Betriebsystemnachrichten gewartet (typischerweise irgendwo im run-loop)

Folgende Eigenschaften sind zu beobachten:

• Bei "defer" werden die Ereignisse streng nacheinander abgearbeitet, bei "immediate" kann es passieren, dass ein Listener von "click" NACH einem Listener von "change" abgearbeitet wird
• "defer" hält künslich eine Ereignisliste vermutlich irgendwo im Heap, während bei "immediate" diese Information implizit durch die Listenerlisten und die Iterationsvariablen auf dem Stack gespeichert hält

Dadurch ergeben sich bei beiden Strukturen verschiedene Vor- und Nachteile durch die Reihenfolge der Abarbeitung. Zum Beispiel gibt es auch parametrisierte Ereignisse, deren Parameter vielleicht irgendwo den Zustand im Programm ändern. Klar, man kann sich als Programmierer auf beides einstellen; aber was gefällt euch mehr? Was findet ihr intuitiver? Seht ihr absolute Totschlagargumente, die absolut gegen die eine Architektur sprechen und für die andere? Habt ihr eine dritte Lösung, die komplett anders aussieht, aber ähnliche Architektur Anforderungen (mehrfache Listener an einem Ereignis, Single Threaded, usw) erfüllen?

Gruß, Brighty

P.S. Ich habe gerade gesehen, dass die Listenabschnitte immer mit "1." anfangen. Der Forensoftware ist mein LIST=5 (bzw. LIST=10) scheinbar nicht Hinweis genug, dass die Liste da mit "5." (bzw. "10.") beginnen soll. Ihr müsst euch die Zahlen entsprechend vorstellen.