Je construis une architecture multiprocessé qui semble être une étrangeusion de la masse d'un pipeline et d'une chaîne de responsabilité. Essentiellement, j'ai une chaîne de gestionnaires liés par des files d'attente. Chaque gestionnaire recevra un objet qui représente les données d'entrée, transmettez-le au gestionnaire suivant afin qu'il puisse commencer à fonctionner dessus, puis déterminer s'il peut tout faire avec ces données.
Je ne crois pas que je puisse appeler cela un pipeline car une étape ne dépend pas vraiment de la suivante. Cela ne semble pas non plus être une chaîne de responsabilité traditionnelle car un gestionnaire ne peut empêcher d'autres gestionnaires de manipuler ces données. Y a-t-il un nom pour cette conception qui m'aidera à documenter cette architecture? Ou est-ce que je vais juste devoir appeler cela quelque chose comme "pipeline de responsabilité"?
3 Réponses :
Cela ressemble plus à la Modèle d'observateur , car chaque gestionnaire est notifié qu'il y a un Changer de l'entrée (via un événement contenant les données).
Je n'avais pas pensé de cette façon. Je suppose que cela a du sens.
Si je comprenais correctement, il a déjà une chaîne d'objets au lieu d'une sorte de diffusion de message, non?
Je pense que la clé du modèle COR est que l'événement est passé jusqu'à ce que quelqu'un le gère, puis il n'est plus transféré. Dans l'exemple op, tous les gestionnaires du processus de file d'attente de la file d'attente l'événement. C'est donc une sorte de diffusion.
OK je vois. Ensuite, la seule différence significative serait si l'ordre dans lequel l'objet est reçu par les gestionnaires est important.
Oui. Dans cet exemple, il existe une forte commande qui n'est pas présente dans l'observateur. J'aurais dû être plus clair sur la façon dont je considère la conception de Jason à ressemblant à l'observateur par opposition à une chaîne de responsabilité, sans être un ajustement parfait.
de votre description, c'est autre chose. La chaîne de responsabilité et le pipeline traitent avec une transformation essentiellement en série. Au moins si je comprends bien votre description correctement, ce que vous avez est essentiellement un certain nombre d'éléments "éléments de processeur" travaillant sur les données en parallèle.
Normalement, vous géreriez une situation comme celle-ci avec un ensemble d'observateurs, mais votre description ne correspond pas vraiment au modèle d'observateur non plus. En particulier, chacun de vos éléments de processeur semble connaître (au moins) un autre élément de processeur. Avec le motif observateur, les observateurs sont normalement inconscités les uns aux autres - chacun se regorgent de la source de données, et lorsqu'il y a des données neuves / modifiées, tous les observateurs sont notifiés par la source de données.
Ma réaction immédiate serait que vous seriez probablement mieux à utiliser le modèle d'observateur au lieu de chercher un nom pour ce que vous avez fait. L'un des points de motif est de résoudre des problèmes similaires de la même manière. Du son des choses, cela serait probablement un peu plus polyvalent et gérable. Par exemple, si vous décidez d'éliminer un observateur de la chaîne, vous devez apparemment modifier un observateur différent de le faire. Avec le modèle d'observateur normal, vous pouvez ajouter ou supprimer des observateurs sans changer d'autre (et sans que les autres ne soient même conscients que tout a changé du tout).
Edit: Étant donné un mélange d'éléments indépendants et chaînés, je vois deux variantes possibles. Le premier (et probablement plus propre) consiste à utiliser le modèle d'observateur au niveau supérieur et certains des observateurs seront eux-mêmes des pipelines.
L'autre possibilité serait de voler un tour des processeurs VLIW, et au niveau supérieur, un drapeau indique si un élément particulier dépend du résultat de la précédente ou non. Cela rend assez facile à mélanger des pipelines avec des observateurs indépendants, et si (par exemple) quelque temps que vous preniez du traitement parallèle, il est assez facile d'exécuter des processus indépendants en parallèle, tout en maintenant une exécution en série pour ceux qui en ont besoin.
Je pense que c'est un cas de choisir entre le moindre de deux maux. Je conviens que l'utilisation d'un modèle d'observateur est probablement préférable, mais il y a quelques étapes qui font constituent un pipeline. Et je sens que les avoir tous en forme avec la même conception globale rendent tout plus compréhensible.
FYI, l'alternative serait probablement plus quelque chose comme ayant un composant qui envoie des messages aux observateurs soit le dernier composant du pipeline. Cela pourrait fonctionner, mais je me sens (comme une question d'opinion) que cette configuration est la plus facile compréhensible. N'oubliez pas que c'est une architecture qui n'a pas utilisé la concurrence auparavant, alors avoir une séquentialité la séquentialité sera probablement plus facile à comprendre.
Je pense toujours que c'est la chaîne de responsabilité, même avec le spécifique de ne pas arrêter la chaîne.
Plusieurs modèles sont très similaires et ont des variations. Je pense que la meilleure façon de voir si un motif convient à un cas cherche son intention. Du livre de gof:
Chaîne de responsabilité "Éviter coupler l'expéditeur d'une demande à son récepteur en donnant plus d'un Object une chance de gérer la demande. Chaîne les objets de réception et passe la demande le long de la chaîne jusqu'à un l'objet le gère. "(pg.223)
Donc, s'il n'y a pas de couplage entre votre gestionnaire et les objets qui traverse la chaîne, je ne pense pas que cela compte que l'objet tombe toujours à la fin de la chaîne, même s'il est manipulé.