Meilleur modèle pour la notification de modification (événements ou délégués)

Question

J'ai une solution où je passe une collection d'éléments d'une source à un présentateur. Lorsque la source est mise à jour, je veux être en mesure d'informer le présentateur pour montrer le nouveau résultat. Ce qui vient à l'esprit est de créer une classe ChangeNotification, de la transmettre avec le résultat et de faire en sorte que cette classe informe le présentateur. Maintenant, comme je le vois, ceci peut être implémenté de deux manières, soit ChangeNotification peut avoir des événements auxquels le présentateur est abonné, ou il peut avoir des délégués que le présentateur définit et les appels source s'il n'est pas nul. L'avantage d'utiliser les événements est que plus que le consommateur peut réagir à la notification et que vous pouvez y connecter des extensions réactives, l'inconvénient est que vous devez gérer l'abonnement/désabonnement des événements pour un nettoyage correct. Les délégués sont simples mais vous perdez de la flexibilité.

Quel est le motif le plus élégant pour une situation comme celle-ci? Y a-t-il un autre moyen auquel je n'ai pas pensé?

Answer 1

Si vous avez plusieurs observateurs, des événements ou des délégués multiples seront nécessaires. Si vous n'avez qu'un seul observateur et que vous voulez l'appliquer, un délégué suffira. Cependant, en ce qui concerne ce qui est le meilleur, à mon humble avis je dirais que l'événement est plus flexible et se prête très bien à la tendance. Les objets ObservableCollection et INotifyPropertyChanged sont des implémentations basées sur des événements. Par ailleurs, +1 à tbischel pour les références à ces classes.

Answer 2

Il existe deux modèles intégrés pour ce scenerio. D'abord, vous pouvez implémenter l'interface INotifyPropertyChanged. Cela est préférable si vous souhaitez informer le présentateur des modifications apportées aux propriétés des objets eux-mêmes dans la collection. (ou l'objet source lui-même, si c'est là que les changements se produisent). Le second est de passer votre présentateur ObservableCollection contenant vos objets. Cela est préférable si vous souhaitez informer le présentateur qu'un élément a été ajouté ou supprimé de la collection. Les deux sont des modèles pilotés par les événements auxquels tout abonné pourrait se connecter.

---

Edit: Le modèle sous-jacent est le modèle "Observer" ... vous pouvez lancer votre propre version si vous voulez, vous avez les détails vers le bas.

Answer 3

Je suis d'accord avec les autres réponses que INotifyPropertyChanged, INotifyCollectionChanged et d'autres interfaces connexes sont la première propriété à tourner, mais je voulais ajouter une troisième option qui implémenterait le modèle d'observateur. Si vous n'êtes pas familier avec ce modèle, c'est comment Java réalise sa fonctionnalité événementielle grâce à ce qu'on appelle event listeners. Il n'y a aucune raison pour que ce modèle ne puisse être adopté en C# et dans certains cas, il peut fournir une solution plus élégante que l'utilisation d'événements et de délégués, surtout lorsqu'il y a plusieurs événements coordonnés généralement souscrits par une partie intéressée.

Une autre option dérive également de DependencyObject et implémente DependencyProperties afin d'obtenir les notifications de modifications intégrées et optimisées pour WPF. J'ai tendance à ne pas suivre cette voie car je n'aime pas l'exigence d'avoir une classe de base spécifique mais il y a de bons arguments pour expliquer pourquoi c'est parfois le bon choix et en fait certains frameworks MVVM l'utilisent même comme base de notifications de changement pour les classes ViewModel aussi.