Je pensais juste à cette question en essayant de trouver du code écrit par notre développeur précédent. Essayer de comprendre comment le programme se déroulait me rappelait le mauvais vieux temps du BASIC, où il n'était presque jamais évident de voir le déroulement d'un programme. Est-ce plus un symptôme d'abus d'événement, ou y at-il un problème structurel avec le modèle d'observateur?Les événements sont-ils l'équivalent OO de GOTO?
Comme toute technologie, les événements peuvent être utilisés de manière incorrecte et abusée. Cependant, puisque vous n'avez donné aucun exemple de votre problème, il nous est pratiquement impossible de dire de quoi vous parlez.
En général, non. Les événements ne sont pas l'équivalent OO de GOTO, et ils ne sont généralement pas un problème. Il n'y a pas non plus de problème structurel avec le modèle d'observateur dont je suis au courant. Mais l'abus peut arriver avec n'importe quoi.
Les GOTO sont mauvais pour beaucoup de raisons, mais l'une des plus importantes est qu'il s'agit d'un transfert de flux de programme, pas simplement une exécution de sous-programme. Lorsque vous utilisez un goto, l'exécution du programme ne revient pas au point après votre appel goto quand il a fini (ou après qu'il a été initié dans le cas d'un événement asynchrone). Le flux de programme est transféré en permanence au nouveau point d'exécution. Ce qui est pire, c'est qu'il peut transférer l'exécution à n'importe où, y compris à l'intérieur d'autres structures de contrôle ou d'autres fonctions.
Les événements n'ont tout simplement pas ces caractéristiques, et sont un peu plus que des pointeurs de fonction avec la conscience de l'objet et une capacité de publication/abonnement. (ok, il y a beaucoup plus que cela, mais c'est leur utilisation de base)
Non, ce n'est pas le cas. Goto est ... euh ... j'ai peur des rapaces ...
Les événements ne sont rien de plus qu'une liste de délégués qui s'appellent un par un. F.e .:
-> Click Event gets called
-> List of associated Event-Handlers
-> Calls every Event-handler/Delegate in the List
+1 pour la référence xkcd – jrummell
La pire chose que j'ai vu avec les événements est l'appel de plusieurs autres événements dans un événement. Un collègue avec qui j'ai travaillé faisait cela constamment. Je pense que cela peut être une situation difficile à traverser, mais c'est encore plus lisible que GOTO.
Pour répondre à votre question, les événements ne sont pas l'équivalent OO de GOTO, puisque GOTO est en soi un mot réservé. Les événements sont différents, les événements suivent le feu et oublient le paradigme où GOTO est «viré mais manipulé de manière procédurale» dans le code. L'utilisation de GOTO peut conduire à des abus résultant du code spaghetti. Néanmoins, le seul moment où GOTO peut être utilisé est dans une situation de récupération d'erreur DANS la portée de la méthode/ou de la fonction. Alors que les événements peuvent être consommés par de nombreux récepteurs, GOTO n'est consommé que par un seul.
Il peut être utile d'utiliser un framework AOP tel que PostSharp où vous pouvez injecter l'AOP dans votre code lors de l'exécution afin de voir le flux et la trace des événements pour mieux comprendre le code.
Espérons que cela aide, Cordialement, Tom.
L'événement n'est pas l'équivalent de GOTO. Cela peut être pire. Les programmeurs se sentent mal quand ils doivent écrire GOTO dans leur code. Avec l'événement, c'est différent. Les gens se sentent accomplis, morderne et cool quand ils utilisent l'événement. J'ai récemment passé du temps à essayer de comprendre un système avec environ 100 classes, 400 événements et 300 enregistrements de gestionnaires. Je comprends ta douleur. Avec Event, il est trop facile de connecter des objets apparemment indépendants. L'événement peut passer ou cacher des relations logiques d'objets et de références et rendre le système entier très difficile à comprendre.
Veuillez fournir plus de détails et/ou un exemple de code. –
Ce n'est pas parce que c'est difficile à comprendre que c'est comme Goto. –
Ce n'est pas parce que c'est difficile à comprendre que ça signifie que c'est mauvais. Certains flux de contrôle sont intrinsèquement compliqués. –