Pourquoi aurais-je utiliser une Chaîne de Responsabilité de plus d'un Décorateur?

Je suis juste à lire sur le La chaîne de Responsabilité modèle et je vais avoir de la difficulté à imaginer un scénario où je préfère son utilisation plus que de décorateur.

Qu'en pensez-vous? Ne CoR avons une niche utiliser?

veuillez ajouter de la nature de la tâche à laquelle vous pensez est une tâche pour le Cdr, mais vous l'avez résolu avec le décorateur
Bien sûr, j'ai besoin de passer une commande et, dans certains cas, j'ai besoin d'imprimer un projet de loi. Mon décorateur solution est d'avoir un noyau OrderCompleter enveloppé dans un OrderCompletionPrintDecorator qui s'applique la logique conditionnelle et d'estampes. Fonctionne tout aussi bien que toute la chaîne.
Pourquoi ne pas juste avoir une méthode appelée "Imprimer" à l'intérieur de OrderCompleter qui peuvent être utilisés (ou pas) quand vous voulez (ne pas vouloir) à imprimer? En d'autres termes, je me demandais si vous pourriez résoudre cette tâche sans l'aide d'aucun motif? Il ne semble pas à moi comme une tâche compliquée, avec un besoin réel pour l'introduction de l'abstraction et de complexité. Ou peut-être ce que vous avez dit est juste une version simplifiée du problème.
Cela dépend - mais oui, c'est une version simplifiée. La question est, où est la logique vont sur ce qui en fait quelque chose d'impression? Si c'est une simple décision qu'elle pourrait aller à droite dans OrderCompleter.Complete() mais il pourrait être quelque chose comme ceci: "Si le service d'impression répond à une commande ping et cet ordre ou un parent de l'ordre n'a pas encore été imprimé et le client de la commande n'intègre pas directement avec notre système."

InformationsquelleAutor George Mauer | 2009-04-14

65

Le fait que vous pouvez briser la chaîne à n'importe quel point qui différencie le modèle Chaîne de Responsabilité de la Décoratrice modèle. Les décorateurs peuvent être considérés comme de l'exécution de toutes à la fois, sans aucune interaction avec les autres décorateurs. Les liens dans une chaîne peut être pensé que l'exécution d'un à la fois, car ils dépendent sur le lien précédent.

Utiliser le modèle Chaîne de Responsabilité lorsque vous pouvez conceptualiser votre programme sous forme d'une chaîne constituée de liens, où chaque lien peut soit gérer une demande ou la passer à la chaîne.

Quand j'ai l'habitude de travailler avec l'API Win32, j'ai parfois besoin d'utiliser l'accrochage fonctionnalité qu'il propose. Accrocher un message de Windows suit à peu près le modèle Chaîne de Responsabilité. Lorsque vous accroché un message WM_MOUSEMOVE, votre fonction de rappel est appelée. Pensez à la fonction de rappel comme le dernier maillon de la chaîne. Chaque maillon de la chaîne peut décider de jeter le message WM_MOUSEMOVE ou de le laisser passer la chaîne sur le lien suivant.

Si le Décorateur modèle a été utilisé dans cet exemple, vous avez été informé du message WM_MOUSEMOVE, mais vous serait impuissante à empêcher d'autres crochets de manutention ainsi.

Un autre endroit de la Chaîne de Commandement motif est utilisé dans des moteurs de jeu. Encore une fois, vous pouvez brancher le moteur, les événements, et d'autres choses. Dans le cas d'un moteur de jeu, vous ne voulez pas de simplement ajouter des fonctionnalités. Vous voulez ajouter des fonctionnalités et empêcher le moteur de jeu de l'exécution de son action par défaut.
- L'OMI Dans le CoR modèle, nous pouvons avoir plusieurs (ou toutes les) gestionnaire (lien), des objets peuvent contribuer à chaque demande de la manipulation ou de la construction d'une réponse.
- Vous dites qu'il pourrait être un remplacement pour un imbriquée instruction if...else, sauf qu'il n'y aura pas d'autre section à la fin?
InformationsquelleAutor William Brendel
17

La différence entre ces modèles n'est pas liée à quand ou comment la chaîne peut être interrompue (qui suppose une chaîne) ou quand le comportement est exécutée. Ils sont liés à la fois utiliser la composition en faveur de l'héritage à fournir une solution plus souple.

La principale différence est qu'un décorateur ajoute nouveau comportement qui, en effet, élargit l'interface d'origine. Il est similaire à la façon normale extension permet d'ajouter des méthodes à l'exception de la "sous-classe" n'est couplé par une référence qui signifie que toutes les "super-classe" peut être utilisé.

Le COR modèle peut modifier un comportement qui est similaire à la redéfinition d'une méthode existante à l'aide de l'héritage. Vous pouvez choisir d'appeler super.xxx() pour continuer sur la "chaîne" ou de manipuler le message vous-même.

Donc, la différence est subtile, mais, par exemple, un décorateur doit permettre:
```
interface Animal
{
    Poo eat(Food food);
}

class WalkingAnimal implements Animal
{
    Animal wrapped;
    WalkingAnimal(Animal wrapped)
    {
        this.wrapped = wrapped;
    }

    Position walk(Human walker)
    {
    };

    Poo eat(Food food)
    {
      return wrapped.eat(food);
    }
}

class BarkingAnimal implements Animal
{
    Animal wrapped;
    BarkingAnimal(Animal wrapped)
    {
        this.wrapped = wrapped;
    }

    Noise bark()
    {
    };

    Poo eat(Food food)
    {
        bark();
        return wrapped.eat();
    }
}
```
Vous pouvez voir que nous pouvons composer une marche, les aboiements de l'animal... ou, en fait, d'ajouter la possibilité de l'écorce de n'importe quel animal. Pour utiliser ce supplément de comportement directement, nous aurions besoin de garder une référence à la BarkingAnimal décorateur.

Tous BarkingAnimal est aussi l'écorce une fois avant de manger ce qui a changé fonctionnalités existantes et est donc similaire à un COR. Mais l'intention n'est pas le même que le CDR c'est à dire de trouver un Animal parmi tant d'autres qui mangent de la nourriture. L'intention, ici, est de modifier le comportement.

Vous pourriez imaginer un COR d'être appliquées pour trouver un homme qui va prendre de l'animal pour une promenade. Cela pourrait être mis en œuvre comme une liste chaînée comme chained ci-dessus ou comme une Liste explicite... ou quoi que ce soit.

Espère que c'est assez clair!

Jean
- C'est la réponse que m'a fait réaliser enfin la j'ai compris de ces modèles a été mauvais! Je pensais structurellement en termes de diagrammes de classes présentées dans le livre, avec la CHAÎNE DE RESPONSABILITÉ d'avoir un résumé de classe parent avec un successeur. Mais GoF notes vous pouvez aussi le faire avec mixin héritage, auquel cas les diagrammes de classe identique. Mais l'élément clé de l'intention et de la différence de comportement, comment, concrètement, le DÉCORATEUR s'élargit à l'interface, est crucial. Grande réponse.
- Merci de m'éclairer d'un animal qui peut manger et de l'écorce dans le même temps, lol.
InformationsquelleAutor John Patterson
13

De la chaîne d'

Éviter le couplage de l'expéditeur d'une demande
à son récepteur en donnant plus de
un objet une chance de traiter l'
demande. La chaîne de la réception des objets
et de transmettre la requête au long de la chaîne
jusqu'à ce qu'un objet qu'il gère.

vs

Décorateur

Joindre d'autres responsabilités à
un objet de façon dynamique. Les décorateurs
fournir une alternative souple à
sous-classement pour l'extension de
la fonctionnalité.

Je dirais autour de l'ordre dans lequel les choses se passent. Si vous avez de la chaîne d'eux, le seront appelés au long de la chaîne. Avec un décorateur vous n'êtes pas garanti cet ordre, seulement que des responsabilités supplémentaires peuvent être attachés.
- Vous pouvez le joindre dans un ordre différent, non?
- Si nous parlons de la POV d'une classe de consommateur, vous avez tout à fait raison, si nous parlons de la POV de la classe concepteur cependant, vous pouvez certainement le garantir autant que la chaîne pourrait.
InformationsquelleAutor Brian
10

Je dirais qu'un de la Chaîne de Responsabilité est une forme particulière de Décorateur.
- Une ligne explique tout
InformationsquelleAutor troelskn
8

Décorateur est utilisé lorsque vous voulez ajouter des fonctionnalités à un objet.

COR est utilisé lorsque l'un des nombreux acteurs qui peuvent agir sur un objet.

Un particulier Décorateur est appelé à prendre une action, basé sur le type; alors que les CO passe de l'objet le long d'une chaîne jusqu'à ce que l'un des acteurs décide que l'action soit terminée.

COR peut être utilisé lorsqu'il y a plusieurs niveaux de l'escalade à des gestionnaires différents-par exemple, un centre d'appel où le client de la valeur à la société détermine si l'appel est acheminé à un niveau particulier de soutien.
- Ok, mais mon point est que vous pouvez utiliser un décorateur avec tout autant si ce n'est moins d'efforts. Alors pourquoi diable même impliquer CoR?
- Mais un décorateur est un modèle différent -- avec le CDR, l'objet est passé d'acteur à acteur jusqu'à ce que l'on dit que c'est terminé l'action; avec le décorateur, l'action est effectuée sur une classe particulière de mise en œuvre.
InformationsquelleAutor Ragoczy
4

Bien que je peux penser de 2 situations:
- Vous ne disposez pas d'un objet de base, c'est à dire que vous ne savez pas quoi faire avec la requête, après avoir passé tous les calques ou les filtres. (quelque chose comme un aspect comme intercepteur chaînes qui ne sont pas vraiment de soins où la demande se termine).
- Vous avez besoin pour appliquer de manière sélective certains pré ou post-traitement de la demande. Pas en général d'amélioration de la forme que le décorateur n'. c'est à dire les Filtres peuvent ou ne peuvent pas gérer une demande spécifique, mais l'ajout d'un décorateur toujours améliore votre objet avec certaines fonctionnalités.
Peut pas penser à un plus en ce moment, aimerait entendre plus à ce sujet.

InformationsquelleAutor MahdeTo
2

Décorateur
1. Décorateur pattern permet de comportement pour être ajouté à un objet de façon dynamique.
2. Il offre une alternative souple à sous classement pour l'extension des fonctionnalités. Même si elle utilise de l'héritage, il hérite de plus petit Dénominateur Commun ( PPDC ) de l'interface.
Diagramme UML pour Décorateur

Conséquences:
1. Avec la décoration, il est également possible de supprimer l'ajout de fonctionnalités de façon dynamique.
2. Décoration ajoute de la fonctionnalité des objets lors de l'exécution, ce qui permettrait de faire la correction de la fonctionnalité du système plus difficile.
Liens utiles:

Quand Utiliser le Pattern Décorateur?

Decorator_pattern de wikipedia

décorateur de sourcemaking

De la chaîne de responsabilité:

De la chaîne de responsabilité de modèle est un modèle de conception comprenant une source d'objets de commande et une série d'objets de traitement. Chaque objet de traitement contient la logique qui définit les types d'objets de commande qu'il peut gérer; le reste est passé à la suivante de la transformation de l'objet dans la chaîne

Diagramme UML

Ce modèle est plus efficace lorsque:
1. Plus d'un objet peut gérer une commande
2. Le gestionnaire n'est pas connu à l'avance
3. Le gestionnaire doit être déterminé automatiquement
4. Il est souhaité que la demande est adressée à un groupe d'objets, sans préciser explicitement son récepteur
5. Le groupe d'objets qui peuvent s'occuper de commande doit être spécifié dans une dynamique de
Liens utiles:

La chaîne de responsibility_pattern de wikipedia

la chaîne de responsabilité-modèle de oodesign

chain_of_responsibility de sourcemaking

Monde réel exemple : Dans une société, un rôle particulier limites du processus de demande d'achat. Si personne désignée rôle n'a pas assez de pouvoir d'approuver les bons de projet de loi, il va de l'avant la commande/demande de son successeur, qui ont plus de pouvoir. Cette chaîne va continuer jusqu'à ce que la commande est traitée.

InformationsquelleAutor Ravindra babu
1

Je suis d'accord que de la structure du point de vue de ces deux modèles sont très similaires. Ma pensée est à propos de la finale de comportement:

Dans l'interprétation classique de CoR élément qui traite la demande brise la chaîne.

Si un élément dans décorateur brise la chaîne, puis il sera mal mise en œuvre de décorateur, parce que la pièce de base de comportement sera perdu. Et l'idée de la décoratrice est transparent à l'ajout de nouvelles comportement lorsque le comportement de base reste intacte.

InformationsquelleAutor xenn_33
1
1. mot clé "extends' - statique extension.
2. Décorateur modèle dynamique d'extension.
3. Modèle chaîne De Responsabilité - juste de la transformation d'un objet de commande avec
  un ensemble de traitement des objets, et ces objets ne connaissent pas les uns les autres.
InformationsquelleAutor Oleksandr Markushyn
0

Je pense que la situation à l'application de ces deux modèles sont différents. Et d'ailleurs, pour le pattern décorateur, le décorateur doit savoir le composant qui l'enveloppa. Et pour le CoR, les différents intercepteurs pouvait rien savoir les uns des autres.
- Le décorateur seulement besoin de savoir l'interface, pas toute mise en œuvre.
InformationsquelleAutor hewei1997
0

Après la lecture de la bande des Quatre définitions, je ne suis pas convaincu il y a une vraie différence. (pour des raisons pratiques)
- Décorateur: Permet la dynamique de l'emballage des objets afin de modifier leurs responsabilités et les comportements
- De la chaîne de Responsabilité: Donne plus d'un objet à l'occasion de traiter une demande en reliant la réception des objets
Wikipedia étoffe un peu, mais certains, elle est un peu arbitraire.
- Décorateur est généralement mis en œuvre comme une Liste chaînée. Mais je pense que c'est trop bas niveau pour être considéré comme "partie intégrante" de la répétition.
- De la chaîne de Responsabilité des liens seulement de traiter les données si il est de leur responsabilité; mais la détermination de la responsabilité et de traitement des données sont à la fois partie du problème. Les décorateurs pouvez le faire aussi facilement.
- Décorateur vous demande d'appeler le délégué.
- Un "pur" CoR lien ne doit appeler le délégué si il ne gère pas les données.
Les deux premiers attributs n'ont pas vraiment de distinguer les modèles. La seconde deux le faire, mais la façon de le Décorateur et le Cdr sont généralement mises en œuvre n'appliquent pas ces attributs--le concepteur espère juste pas écrit un Décorateur qui rompt la chaîne ou d'une CoRLink qui continue la chaîne après la manipulation des données.

De mise en œuvre de ces attributs, vous auriez besoin de quelque chose comme ce qui suit.

Forcée Décorateur:
```
abstract class Decorated {

public Decorated delegate;

public final Object doIt(Object args) {
    Object returnVal = behavior(arg);
    if(delegate != null) returnVal = delegate.doit(returnVal);
    return returnVal;
}

protected abstract Object behavior(Object args); //base or subclass behavior
}
```
Forcée de la Chaîne de Responsabilité:
```
abstract class Link {

public Link delegate;

public final Object processIt(Obect args) {
    Object returnVal = args;
    if(isMyResponsibility) returnVal = processingBehavior(returnVal);
    else returnVal = delegate.processIt(returnVal);
    return returnVal;
}

protected abstract Boolean isMyResponsibility(Object args);

protected abstract Object processingBehavior(Object args);
}
```
(Alternativement, vous pouvez simplement ajouter une ligne à la javadoc, si tout ce que vous voulez, c'est de s'absoudre de la responsibiity dans le cas où quelqu'un d'autre vis de votre conception--mais pourquoi laisser faire le hasard?)

InformationsquelleAutor Kevin Sagan

Vous devez vous connecter pour publier un commentaire.