Callback Prinzip, stucked

Hi,

Ich versuche hier grade ein Callback Prinzip zwecks EventHandling durchzuplanen, und hänge ein wenig fest.

1. Ich registriere für ein Objekt "O1" im EventHandler einen Event "EV_1", genaugenommen aber einen Zeiger auf eine Methode in O1, die EV_1 behandelt.
2. Irgendwann wird Irgendwo EV_1 geworfen und in die Queue im EventHandler abgelegt.
3. Der EventHandler sieht den Event und durchwandert alle dafür registrierten Objekte, bzw. ruft die entsprechende Methode auf, deren Zeiger zu dem Event registriert wurde.
4. Die Methode in O1 sollte nun den Event bearbeiten. Allerdings bringt EV_1 ein paar Parameter mit sich. Da EV_1 tatsächlich einfach nur ein Enum zur Identifikation ist, weiß ich nicht wie ich diese schön Implementiere.

Kann mit vielleicht Jemand für Doofe erklären, wie dieses Callback Prinzip aussieht? Herrvorragend wäre es auch, wenn kein Casting innerhalb der Event-Verarbeitenden Methoden nötig wäre. Ich schaffe den Schritt zwischen enums zur Eventdeklaration nicht und die Übergabe der Parameter. Ich kenne mich aber im allegemeinen mit Callback nicht aus...

Vielen Dank für eure Hilfe!

Termite

Hi

kann jetzt sein, das ich was nicht verstehe. du redest hier von callback. einem prinzip das aus der structurirten programierung kommt. Anderer seits redest du von Objekten.

Ich nehm mal an du meinst das Observer pattern nur wüst ich da nicht wo man da casten müsste, wenn man das sauber ableitet ( mit schönnen interfaces/ abstracten classen und so)

schau dir dazu ggf mal das eventhandling von java/awt bzw java/swing an. ist vileicht das was du suchst.

Du hast
a. ein zentrales eventobject. das als eizigstes feld eine EventID besitzt
b. ein spezielles eventobject, das von a abgeleitet ist, die EventID definiert sowie platz für die notwendigen parameter bereithält.
c. ein interface, mit einer Abstracyten Methode die als parameter das object aus a hat ( deine callback methode )
d. eine classe / object das c implementirt ( dein object "O1") Diese Klasse implementiert die Methode und überprüft als erstes bei einem aufruf ob der parameter auch den typ hat, der verarbeitet werden kann. danach wird auf den passenden typ gekastet und die parameter abgeholst und ausgewertet.

e. deine EventQueue arbeit eigentlich wie bisher. Objecte die das Interface aus c implementieren werden mit der EventID registriert und in eine interne verwaltungsstrucktur einsortiert. Tauch ein event auf. werden die passenden Objekte gesucht. und das eventobjekt übergeben.

das system liese sich sicher noch in einigen punkten verbessern

ich hoffe ich hab mich verständlich ausgedrückt

gruss Termite

Also impliziert dein Modell, dass ich für jedes Event ein korrespondierendes Objekt benötige. Sehe ich das so richtig?

HumeSikkins

Termite schrieb:

nur wüst ich da nicht wo man da casten müsste

Im Handler-Code für benutzer-definierte Events. Spätestens wenn diese Datenmember besitzen (-> Push-Modell) auf die du zugreifen willst, musst du hier downcasten. Eine one-size-fits-all-Schnittstelle kann es schließlich nicht geben.

Man vergleiche dazu die Diskussion der Patterns Multicast bzw. Typed Message vs. Observer.

@CallBack0r
Schau dir mal boost::signal an.
Und falls dir langweilig ist vielleicht auch:
http://fara.cs.uni-potsdam.de/~kaufmann/libevent/index.html