Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Calback et événements : quel lien(s) entre ces 2 notions ?
Je comprends bien la notion d'événement, et j'utiilse souvent les callback des librairies.
En revanche quand je dois concevoir une architecture, je bute toujours sur ces 2 notions : je me demande toujours si je dois créer un événements et son écouteur, ou une callback, ou des siganl/slot... ?
Bref c'est le brouilllard.
Pouvez vous m'aider à distinguer ces termes ?
Sur quelle plate-forme ? Même si tout ces concepts sont généraux, c'est surtout en fonction de cela qu'on utilisera plus les uns que les autres.Envoyé par ttone
Un « écouteur » est un objet qui se met à l'écoute d'un événement particulier. Donc pour cela, il faut qu'il y ait une file d'événements, et quelque chose à appeler lorsque l'événement surveillé survient.
La seule différence, de mon propre point de vue, est qu'en général, un écouteur est un objet qui respecte une interface prédéfinie. La boucle principale sait alors à l'avance quelle méthode appeler. Il n'en reste pas moins que cette méthode est en elle-même une fonction de call-back (l'objet se déclare auprès d'un tiers, qui le « rappelle » en temps voulu), même si tu n'as pas eu besoin de la spécifier explicitement.
Il y a au moins trois concepts:
- des événements qui doivent être traîtés, donc par un seul destinataire, même si celui-ci peut n'être déterminé que par un pattern de chain of responsability; l'événement lui-même est souvent, mais pas toujours, réifié par l'utisation du pattern command.
- le pattern publisher/observer où les observeurs peuvent naturellement être plusieurs. On peut aussi appeler événements les notifications qu'ils recoivent.
- les callbacks sont des fonctions qu'on passe pour qu'elles soient appelées par après. C'est un mécanisme d'assez bas niveau qui peut servir entre autres pour implémenter les deux patterns ci-dessus.
Merci, je commence àà bien mieux cerner l'ensemble.
Le wikipedia des callbacks est assez bien :- les callbacks sont des fonctions qu'on passe pour qu'elles soient appelées par après. C'est un mécanisme d'assez bas niveau qui peut servir entre autres pour implémenter les deux patterns ci-dessus.
http://en.wikipedia.org/wiki/Callback_function
Pouvez vous m'aider sur un cas concret ? J'ai du mal
J'ai 3 classes :
* Ampli.class
* Guitare.class
* Jack.class
Le jack se plugge sur l'ampli et sur la guitare.
Le tout sont des éléménent représentés graphiquement.
Ces 3 classes sont instanciées dans le main.
L'objectif est le suivant : lorsque l'utilisateur déplace la guitare ou l'ampli, le jack doit être redessiné de manière à maintenir la connection.
Guitare et ampli ont une fonction callback pertinente : moved()
J'aimerai pouvoir faire réagir mon jack à l'appel de cette fonction.
A la création , le jack se voit attribué 2 pointeurs : pGuitare, pAmpli.
Que dois je faire conceptuellement parlant :
1. pointer sur ampli et guitare dans Jack.class et créer un callback dans Jack,
dans lequel j'assurerai le redimensionnement de mon jack grâce au donnée que je récupère sur guitare et ampli ?
2. pointer sur le jack depuis Ampli.class et Guitar.class, et assurer son repaint depuis ces objets ?
J'en suis à la solution 1 : elle me semble plus pertinente, en tous cas plus claire. Mais relier un callback de A sur un callback de B...
Salut,
De prime abord, je dirais que tu n'a même pas besoin d'avoir un pointeur de type ampli ni de type guitare de ta classe jack...
Tu pourrais te contenter d'une fonction surchargée (un exemplaire qui reçoit une référence constante de type guitare et l'autre qui reçoit une référence constante de type ampli), que tu nommerais éventuellement d'un nom un peu plus pertinent que "redraw()" et qui serait appelée par tes méthodes moved...
Ce serait alors la guitare et l'ampli qui auraient un pointeur vers la prise jack, en somme, afin de pouvoir appeler redraw(*this)
Pour moi, l'idée est que, comme on sait pertinemment quand exactement la fonction devra être appelée, il n'y a pas vraiment lieu de gérer cela par événement ou callback d'aucune sorte
A méditer: La solution la plus simple est toujours la moins compliquée
Pour répondre à cette question là en particulier : tu vas généralement avoir besoin d'une fonction de call-back pour réagir à des événements. C'est encore ce qu'il y a de plus simple.
Cependant, on utilise des fonctions de call-back dans bien d'autres cas de figures : typiquement les tris, où la fonction qui embarque l'algo de tri proprement dit rappelle ta fonction pour faire une comparaison. Cette façon de faire te permet de trier n'importe quel type d'objets, mais il n'y pas de notion d'événements dans ce processus. Juste une bête boucle dont les appels sont prédictibles.
Répondre avec citation
Partager