Au travail, nous avons un cadre énorme et utilisez des événements pour envoyer des données d'une partie à une autre. J'ai récemment commencé un projet personnal et je pense souvent à utiliser des événements pour contrôler les interactions de mes objets.
Par exemple, j'ai une classe de mixage qui joue des effets sonores et je pensais initialement que je devrais recevoir des événements pour jouer un effet sonore. Ensuite, j'ai décidé de ne faire que ma classe statique et d'appeler dans mes classes. J'ai une tonne d'exemples comme celui-ci où j'avais initialement penser à une mise en œuvre avec des événements, puis changer mon esprit, me disant qu'il est trop complexe pour rien. Alors, quand dois-je utiliser des événements dans un projet ? Dans lesquels les événements d'occasions ont un avantage sérieux par rapport aux autres techniques?
4 Réponses :
Vous utilisez généralement des événements pour notifier des abonnés à propos de certaines modifications d'action ou d'état survenues sur l'objet. En utilisant un événement, vous laissez différents abonnés réagir différemment et en découplant l'abonné (et sa logique) à partir du générateur d'événements, l'objet devient réutilisable.
Dans votre exemple de mélangeur, j'aurais des événements signaler le début et la fin de la lecture de l'effet sonore. Si je devais l'utiliser dans une application de bureau, je pourrais utiliser ces événements pour activer / désactiver les contrôles de l'interface utilisateur.
La différence entre appeler un sous-programme et une levée d'événements a trait à: Spécification, élection, cardinalité et finalement, de quel côté, l'initiateur ou le récepteur a le contrôle.
Avec les appels, l'initiateur élit pour appeler la routine de réception et l'initiateur spécifie le récepteur. Et cela conduit à de nombreux contre-one cardinalité , car de nombreux appelants peuvent choisir d'appeler le même sous-programme.
Avec des événements d'autre part, l'initiateur soulève un événement qui sera reçu par ces routines qui les ont élues pour recevoir cet événement. Le récepteur spécifie quels événements il recevra des initiateurs. Cela conduit ensuite à une cardinalité comme une source d'événement peut avoir de nombreux récepteurs.
Ainsi, la décision d'appels ou d'événements, surtout à faire si l'initiateur détermine le récepteur ou que le récepteur détermine l'initiateur.
C'est un compromis entre la simplicité et la réévaluabilité. Permet de prendre une métaphore de "envoyer le courrier électronique":
Si vous connaissez les destinataires et qu'ils sont finis en nombre que vous pouvez toujours déterminer, c'est aussi simple que de les mettre en liste "to" et frapper le bouton d'envoi. C'est simple comme c'est ce que nous utilisons la plupart du temps. Ceci appelle directement la fonction.
Cependant, dans le cas de la liste de diffusion, vous ne savez pas à l'avance que le nombre d'utilisateurs vont vous abonner à votre courrier électronique. Dans ce cas, vous créez un programme de liste de diffusion dans laquelle les utilisateurs peuvent s'abonner et le courrier électronique se passe automatiquement à tous les utilisateurs souscrits. C'est la modélisation des événements.
Maintenant, même si, dans l'option ci-dessus, des courriels sont envoyés aux utilisateurs, vous êtes un meilleur juge de quand envoyer un courrier électronique directement et quand utiliser le programme de la liste de diffusion. Appliquez le même jugement, espérons que vous obtiendrez votre réponse :)
acclamations,
ajit.
J'ai travaillé avec une base de code énorme à mon lieu de travail précédent et j'ai vu que l'utilisation d'événements peut augmenter beaucoup la complexité et souvent inutilement.
J'avais souvent un code d'ingénieur en ingénieur pour le réparer ou l'étendre. Dans les deux cas, il est beaucoup plus facile de comprendre ce qui se passe, lorsque vous pouvez simplement lire une liste des appels de fonction au lieu de voir simplement l'augmentation d'un événement.
L'événement vous oblige à rechercher des usages afin de bien comprendre ce qui se passe. Pas un problème avec les IDes modernes, mais si vous rencontrez ensuite de nombreuses fonctions, qui soulèvent également des événements, il devient rapidement complexe. J'avais rencontré des cas, où cela importait dans quelles fonctions d'ordre s'est présentée à un événement, même si la plupart des langues ne sont même pas gurantee un ordre d'appel ...
Il y a des cas quand c'est une très bonne idée d'utiliser des événements. Mais avant de commencer à partir, considérez l'alternative. Il est probablement plus facile de lire et de la manuelle.
Un exemple classique pour l'utilisation d'événements est un cadre UI, qui fournit des éléments tels que des boutons, etc. Vous voulez la fonction "Buttonprimé ()" du cadre pour appeler certaines de vos fonctions, de sorte que vous puissiez réagir à l'action de l'utilisateur. L'alternative à un événement que vous pouvez souscrire, ce serait par exemple un «boutonnière de boutonnière» de Bool public, que le cadre UI expose et sur lequel vous pouvez régler la vérification de la réalité de la véritable ou de la fausse. Ceci est bien sûr très inefficace, quand il y a des centaines d'éléments d'interface utilisateur.