Quels sont les symptômes dans une base de code qui indiquent qu'une approche d'écoute d'événements est requise?
Il me semble que lorsqu'il y a des classes qui doivent être appelées par plusieurs, non définies au moment de la conception des autres classes, vous avez besoin d'une sorte de cadre de signalisation, mais j'aimerais entendre quelles autres situations y aurait-il améliorée en passant à un modèle basé sur les événements.
Réponses:
L'approche Event / Listener essaie d'éviter un couplage serré , de sorte que tout le code qui le sent pointerait vers l'approche.
Sur cette base, je suggère les symptômes suivants:
grands constructeurs , car chaque objet a besoin de connaître tous les autres objets, et ne peut pas fonctionner sans. Peut-être déguisé autant de personnes obj.set_dependecy(x)immédiatement après l'appel du constructeur.
dépendances bidirectionnelles , car, sans événements, dans un langage impératif, le flux d'informations est fondamentalement «push» (appel de la méthode someones)
la «hiérarchie des connaissances» est difficile à déterminer . Ce sont les dépendances bidirectionnelles , juste un autre focus: s'il y a A, qui écoute B, A connaît B, mais B ne fait pas A, donc il y a une 'hiérarchie': certains objets ne savent rien, certains en connaissent d'autres , etc. Par exemple, lors de l'implémentation de MVC comme ceci: http://en.wikipedia.org/wiki/Model_View_Controller , le modèle ne se connaît que lui-même, la vue connaît le modèle et le contrôleur connaît la vue et le modèle.
Lorsque vous ne pouvez pas ou ne devez pas savoir ce qui doit réagir à un ensemble de messages / signaux / événements.
Souvent, c'est quand vous voulez que "le monde" sache quelque chose qui se passe dans un module (une classe ou un système de classes) mais vous ne voulez pas vous soucier de ce qu'on appelle.
L'odeur de code associée, pour être précis, est lorsque vous sentez que vous commencez à mélanger du code à partir de modules indépendants, l'un faisant quelque chose auquel l'autre devrait réagir. Une fois que vous voyez que vous devez appeler le code du module B en fonction de l'état / des événements du module A, vous avez besoin d'écouteurs d'événements.
Je changerais votre question et dirais: quand un événement n'est pas la bonne solution pour une application orientée objet? Je pense que la plupart des applications OO peuvent bénéficier si elles sont conçues comme des producteurs et des consommateurs d'événements.
En fin de compte, un "appel de méthode" est en fait un message arrivant à un objet et l'objet est responsable de décider s'il va faire quelque chose avec le message et effectuer l'opération. Ce n'est pas très clair dans les langages fortement typés comme Java, mais cela devient plus évident dans les langages dynamiques comme Ruby.
Un autre point intéressant de la conception d'une application basée sur des événements est que les composants internes doivent généralement être correctement isolés et cohérents, sinon le code devient un gâchis très, très rapidement. À titre d'exemple, j'aime beaucoup le concept d' architecture hexagonale utilisé par Alistair Cockburn, car généralement ce modèle crée une meilleure encapsulation et force (à mon avis) des composants plus cohésifs.
Je pense (mais je me trompe probablement) que cela est également lié au concept de conception pilotée par le domaine des événements de domaine , dans lequel les classes de domaine émettent des événements capturés par d'autres objets, et ces objets émettent encore d'autres événements (vous voyez où cela va: D). Ce que j'aime dans ce modèle, c'est que les interfaces doivent modéliser les rôles, pas les implémentations.
Désolé si je n'ai pas beaucoup de sens, j'ai expérimenté ces modèles au cours des derniers mois avec des résultats incroyables, mais j'essaie toujours de comprendre les concepts et jusqu'où ils vont.
Pensez à ce que vous auriez à faire si les écouteurs d'événements (alias le modèle d'observateur) n'existaient pas.
Si vous avez un objet qui fait référence à une liste d'autres objets et appelle une méthode sur eux à un moment donné du processus, vous devriez certainement y avoir eu un événement.
Si vous avez un indicateur sur un objet pour indiquer que quelque chose a été fait et que vous observez cet indicateur à partir d'autres objets, vous devriez certainement avoir utilisé un modèle piloté par les événements.
Cependant, ne confondez pas cela avec un rappel. Si vous appelez une méthode sur un autre objet et lui transmettez une méthode sur l'objet d'origine à rappeler à un moment donné, vous devez la laisser de cette façon, plutôt que d'utiliser un écouteur d'événements.