Les événements sont-ils l'équivalent OO de GOTO ?

Question

Je pensais justement à cette question en essayant de comprendre un code écrit par notre ancien développeur. Essayer de retracer comment le contrôle du programme se passait m'a rappelé le mauvais vieux temps du BASIC, où le chemin d'exécution d'un programme n'était presque jamais évident. S'agit-il plutôt d'un symptôme d'abus d'événements ou d'un problème structurel avec le modèle d'observateur ?

Answer 1

Comme toute technologie, les événements peuvent être utilisés de manière incorrecte et abusive. Cependant, comme vous n'avez donné aucun exemple de votre problème, il nous est pratiquement impossible de savoir de quoi vous parlez.

En général, non. Les événements ne sont pas l'équivalent OO de GOTO Ils ne constituent pas non plus un problème typique. Il n'y a pas non plus de problème structurel dans le modèle de l'observateur, à ma connaissance. Mais des abus peuvent se produire avec n'importe quoi.

Les GOTO sont mauvais pour de nombreuses raisons, mais l'une des plus importantes est qu'il s'agit d'un transfert du flux du programme, et pas seulement de l'exécution d'une sous-routine. Lorsque vous utilisez un goto, l'exécution du programme ne revient pas au point qui suit votre appel goto lorsqu'il est terminé (ou lorsqu'il a été initié dans le cas d'un événement asynchrone). Le flux du programme est transféré de façon permanente vers le nouveau point d'exécution. Le 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 ne sont guère plus que des pointeurs de fonction avec une conscience d'objet et une capacité de publication/abonnement. (ok, il y a beaucoup plus que cela, mais c'est leur utilisation de base)

Answer 2

Non, ça ne l'est pas. Goto est... ahm... J'ai peur des raptors...

Les événements ne sont rien de plus qu'une liste de délégués qui sont appelés un par un. Par exemple :

-> Click Event gets called
    -> List of associated Event-Handlers
        -> Calls every Event-handler/Delegate in the List

Answer 3

La pire chose que j'ai vue avec les événements est l'appel de plusieurs autres événements dans un même événement. Un collègue avec qui je travaillais le faisait constamment. Je pense que c'est une situation qui peut être difficile à traverser, mais c'est toujours plus lisible que GOTO.

Answer 4

Pour répondre à votre question, les événements ne sont pas l'équivalent OO de GOTO, car GOTO est en soi un mot réservé. Les événements sont différents, ils suivent le paradigme "tirer et oublier", alors que GOTO est "tiré mais traité de manière procédurale" dans le code. L'utilisation de GOTO peut conduire à des abus et à un code spaghetti. Néanmoins, la seule fois 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 est consommé par un seul.

Il pourrait valoir la peine d'utiliser un cadre AOP tel que PostSharp où vous pouvez obtenir la POA injectée dans votre code au moment de l'exécution afin de voir le flux et la trace des événements pour aider à mieux comprendre le code.

J'espère que cela vous aidera, Meilleures salutations, Tom.

Answer 5

Event 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 Event, c'est différent. Les gens se sentent accomplis, modernes et cool quand ils utilisent Event. J'ai récemment passé du temps à essayer de comprendre un système avec environ 100 classes, 400 événements et 300 enregistrements de handlers. Je comprends votre douleur. Avec Event, il est trop facile de relier des objets apparemment indépendants. Event peut contourner ou cacher les relations logiques des objets et des références et rendre l'ensemble du système très difficile à comprendre.