Dans quelle mesure devez-vous affiner vos Observables / Listenables?

Question

Vous disposez d'un Observable / Listenable orienté vers la traction qui informe les observateurs / auditeurs lorsque certains états changent.

L’état se compose de plusieurs pépites de données et certains de vos observateurs / auditeurs ne se soucient pas de l’ensemble de l’état.

Préférez-vous généralement avertir tous les observateurs / auditeurs de toute façon et leur permettre d'ignorer les notifications lorsque rien ne les préoccupe ne change?

Ou préférez-vous généralement un observable séparé pour chaque "pépite"? des données afin que vos observateurs / auditeurs soient assurés de ne recevoir que les notifications dont ils ont besoin pour répondre?

Cela dépend-il de la situation?

Avez-vous des idées générales sur la granularité de vos observables / écoutes?

Answer 1

Vous négociez les coûts de maintenance par rapport aux coûts de livraison. Si vous avez des définitions d'événement précises, chaque observateur ne reçoit que exactement ce dont il a besoin. Vous ne payez donc pas les frais généraux liés à la livraison à des observateurs indifférents. système en quelque sorte.

Dans les systèmes de messagerie Pub / Sub où les coûts de livraison sont relativement élevés (messages circulant sur les réseaux), il est généralement nécessaire de prêter une attention particulière aux définitions de sujet. Une hiérarchie de sujets soigneusement conçue est souvent utile. Donc, nous obtenons des modèles comme

  sport
       football
              england 
                    premier
                    champioship
              scotland
                    spl
              france
                    ...
       cricket
              australia
                    ...
              india
              sri lanka

Donc, autoriser les abonnements à différents niveaux. Vous pouvez vous abonner à tous les sports ou (comme certains pourraient le faire) jusqu'à

    sport/football/england/championship/watford

Answer 2

En règle générale, les interfaces spécialisées font plus de bien que de mal, alors je mettrais certainement en œuvre plus que moins.

Cela appelle évidemment à la situation. Ne vous spécialisez de cette manière que si cela est nécessaire, et de votre point de vue, cela semble bien être, sinon c'est comme si on informait les fabricants de céréales que le blé doit être récolté. Cela ne s'applique tout simplement pas.

Answer 3

Si je devais le faire, je créerais probablement une classe Observable qui aurait un événement pour chaque type de pépite et un événement global pour chaque pépite. Un peu comme un moyen chemin.

Answer 4

Ce n’est pas seulement de la maintenance. Plus l'interface entre observables et observateurs est spécifique, plus ils deviennent couplés.

Le livre Gang Of Four a une section pour ce problème même, et déconseille à la fois les modèles push et pull. Le modèle tiré peut être inefficace, le modèle push peut ne pas être suffisamment réutilisable.

Donc, cela dépend fortement de la situation. J'ai tendance à aller légèrement au-dessus du modèle à traction.