Quelqu'un peut-il signaler les principales différences entre les deux?
Il semble que, au moins conceptuellement, les deux sont très étroitement liés. Si je devais endommager une supposition, je dirais que la méthode de publication / souscription est un sous-ensemble du modèle de médiateur (car le médiateur n'a pas besoin de ne pas nécessairement être utilisé de manière publiée / souscription, mais ce dernier semble nécessiter une sorte de médiateur objet). Est-ce que c'est n'importe où près de lui?
5 Réponses :
Selon Cette page , le modèle de publication-abonnement est une implémentation de la Modèle de médiateur.
Modifier
Je dois noter que les modèles de conception sont appelés «motifs» précisément parce qu'il y ait des différences entre chaque mise en œuvre. Ils ne sont pas tellement un ensemble de formes cancéreuses décrétées, car elles constituent une collection d'observations sur la façon dont les gens écrivent déjà des logiciels. Donc, il n'y a donc vraiment aucun moyen d'un design à "strictement" adhérer à un modèle de conception.
Comment je décrirais la différence est que, dans le médiateur, vous vous souciez probablement si l'application finale reçoit le message. Donc, vous utilisez cela pour garantir qui reçoit le message. Alors que avec pub / sous vous vient de publier votre message. S'il y a des abonnés, ils l'obtiendront, mais vous ne vous souciez pas.
Je pense qu'un point principal de différence est le contexte du problème.
Bien qu'un problème puisse être résolu avec l'un ou l'autre modèle, les vraies préoccupations sont les suivantes:
1: «Quelle quantité de changement pour entraîner les événements dépendent du contexte général?»
2: "À quelle fréquence les auditeurs devraient-ils changer?"
Le cas classique du motif de médiateur illustre le mieux ceci où vous avez une interface utilisateur complexe avec de nombreux composants et que la mise à jour de chacune a une intercendance complexe sur l'état d'autres composants similaires.
Bien que vous puissiez résoudre ce problème avec le pub / sous-modèle; dans lequel vos composants écoutent des événements et contiennent la logique nécessaire à la mise à jour, l'objet contextuel (ainsi que l'événement) portent toutes les informations nécessaires. Ici, l'avantage est évidemment l'encapsulation appropriée de la logique relatif à un composant en soi. L'inconvénient est que si ces composants sont censés changer souvent, vous devez répliquer cette logique complètement dans chaque nouveau composant que vous apportez.
Pour utiliser un médiateur consiste à introduire une autre couche et d'abstrait supplémentaire des composants. Ces composants deviennent plus minces car ils ne traitent que de représentation (l'apparence de l'interface utilisateur et la sensation) sont donc très faciles à changer. Le seul problème que j'ai avec cette approche est que la logique de mise à jour semble désormais renversée à d'autres composants et toute mise à jour du système nécessiterait une pour modifier le composant et le médiateur si le comportement du composant doit également changer.
Pour moi, c'est le grand dilemme / compromis que nous devons résoudre. S'il vous plaît corrigez-moi si je n'ai rien eu correctement.
La mise en œuvre pourrait être la même, mais logiquement, elles sont différentes (la différence est simple, mais il est difficile de voir). Je vais l'expliquer de manière simple ci-dessous.
de manière de manière de manière de manière de manière de manière de manière de la mise en œuvre du modèle de publication / abonnement, vous aurez au moins un objet avec les méthodes "Publier" et "S'abonner". Mais vous pouvez aussi en avoir aussi plus d'entre eux. La communication entre les composants n'est pas centralisée par définition.
Dans la mise en œuvre du motif de médiateur, vous n'aurez qu'un seul objet avec des méthodes "Publier" et "S'abonner". La communication est donc "centralisée" par définition.
Dans le livre GOF, Publish / Subscribe est connu sous le nom de modèle d'observateur . Le motif de médiateur peut être mis en œuvre à l'aide du motif observateur; Mais ce n'est pas le seul moyen de mettre en œuvre un médiateur. Le livre décrit cela à la page 278.
communication de collègue-médiateur . Les collègues doivent communiquer avec leur médiateur lorsqu'un événement d'intérêt survient. Une approche consiste à mettre en œuvre le médiateur en tant qu'observateur à l'aide du modèle d'observateur. Les classes de collègues agissent en tant que sujets, envoyant des notifications au médiateur chaque fois qu'ils changent d'état. Le médiateur répond en propagant les effets du changement à d'autres collègues.
Une autre approche définit une interface de notification spécialisée dans le médiateur qui permet aux collègues d'être plus directes dans leur communication ... lors de la communication avec le médiateur, un collègue se transmet comme un argument, permettant au médiateur d'identifier l'expéditeur.
Notez que même lors de la mise en œuvre d'un médiateur en tant qu'observateur, il est décrit comme communiquant uniquement parmi ses collègues, tandis qu'un observateur en général communiquerait également avec d'autres objets.