Why would I ever use a Chain of Responsibility ove

问题:

I'm just reading up on the Chain of Responsibility pattern and I'm having trouble imagining a scenario when I would prefer its use over that of decorator.

What do you think? Does CoR have a niche use?

回答1:

The fact that you can break the chain at any point differentiates the Chain of Responsibility pattern from the Decorator pattern. Decorators can be thought of as executing all at once without any interaction with the other decorators. Links in a chain can be thought of as executing one at a time, because they each depend on the previous link.

Use the Chain of Responsibility pattern when you can conceptualize your program as a chain made up of links, where each link can either handle a request or pass it up the chain.

When I used to work with the Win32 API, I would sometimes need to use the hooking functionality it provides. Hooking a Windows message roughly follows the Chain of Responsibility pattern. When you hooked a message such as WM_MOUSEMOVE, your callback function would be called. Think of the callback function as the last link in the chain. Each link in the chain can decide whether to throw away the WM_MOUSEMOVE message or pass it up the chain to the next link.

If the Decorator pattern had been used in that example, you would have been notified of the WM_MOUSEMOVE message, but you would be powerless to prevent other hooks from handling it as well.

Another place the Chain of Command pattern is used is in game engines. Again, you can hook engine functions, events, and other things. In the case of a game engine, you don't want to simply add functionality. You want to add functionality and prevent the game engine from performing its default action.

回答2:

The difference between these patterns is not related to when or how the chain can be broken (which assumes a chain) or in when the extra behaviour is executed. They are related in that they both use composition in favour of inheritance to provide a more flexible solution.

The key difference is that a decorator adds new behaviour that in effect widens the original interface. It is similar to how normal extension can add methods except the "subclass" is only coupled by a reference which means that any "superclass" can be used.

The COR pattern can modify an existing behaviour which is similar to overriding an existing method using inheritance. You can choose to call super.xxx() to continue up the "chain" or handle the message yourself.

So the difference is subtle but an example of a decorator should help:

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();
    }
}

You can see that we can compose a walking, barking animal... or in fact add the ability to bark to any animal. To use this extra behaviour directly we would need to keep a reference to the BarkingAnimal decorator.

All BarkingAnimal's also bark once before eating which has changed existing functionality and so is similar to a COR. But the intent is not the same as COR i.e. to find one Animal of many that will eat the food. The intent here is to modify the behaviour.

You could imagine a COR being applied to find a human that will take the animal for a walk. This could be implemented as a linked list like chained above or as an explicit List... or whatever.

Hope this is reasonably clear!

John

回答3:

Chain

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

vs

Decorator

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

I'd say its around the order in which things will happen. If you chain them, the will be called along the chain. With a decorator you're not guaranteed this order, only that additional responsibilities can be attached.

回答4:

I'd say that a Chain of Responsibility is a particular form of Decorator.

回答5:

Decorator is used when you want to add functionality to an object.

COR is used when one of many actors might take action on an object.

A particular Decorator is called to take an action, based on the type; while COR passes the object along a defined chain until one of the actors decides the action is complete.

COR might be used when there are multiple levels of escalation to different handlers -- for instance, a call center where the customer's value to the company determines if the call goes to a particular level of support.

回答6:

Well I can think of 2 situations:

• You don't have a core object, i.e. you don't know what to do with the request after it passed all the layers/filters. (something like an aspect like interceptor chains that don't really care where the request ends).
• You need to selectively apply some pre or post processing to the request. Not in a general enhancement form as the decorator does. i.e. Filters may or maynot handle a specific request but adding a decorator always enhances your object with some functionality.

Can't think of any more right now, would love to hear more in this topic.

回答7:

Decorator

1. Decorator pattern allows behaviour to be added to an individual object dynamically.

2. It provides a flexible alternative to sub classing for extending functionality. Even though it uses inheritance, it inherit from Lowest Common Denominator ( LCD ) interface.

UML diagram for Decorator

Consequences:

1. With decoration it is also possible to remove the added functionalities dynamically.
2. Decoration adds functionality to objects at runtime which would make debugging system functionality harder.

Useful links:

When to Use the Decorator Pattern?

Decorator_pattern from wikipedia

decorator from sourcemaking

Chain of responsibility:

Chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain

UML Diagram

This pattern is more effective when:

1. More than one object can handle a command
2. The handler is not known in advance
3. The handler should be determined automatically
4. It’s wished that the request is addressed to a group of objects without explicitly specifying its receiver
5. The group of objects that may handle the command must be specified in a dynamic way

Useful links:

Chain-of-responsibility_pattern from wikipedia

chain-of-responsibility-pattern from oodesign

chain_of_responsibility from sourcemaking

Real world example : In a company, a designated role have particular limits to process purchase request. If person with a designated role does not have enough power to approve purchase bill, he will forward the command/request to his successor, who have more power. This chain will continue until the command is processed.

回答8:

I agree that from structural standpoint this two patterns are very similar. My thought is about the final behavior:

In the classic interpretation of CoR element which handles the request breaks the chain.

If any element in decorator breaks the chain then it will be wrong implementation of decorator, because base part of behavior will be lost. And the idea of decorator is transparent addition of new behavior when the base behavior remains untouched.

回答9:

1. keyword 'extends' - static extension.
2. Decorator pattern - dynamic extension.
3. Chain Of Responsibility pattern - just processing of a command object with a set of processing objects and those objects don't know each other.

回答10:

I think the situations to apply these two patterns are different. And by the way, for decorator pattern, the decorator should know the component which it wrapped. And for CoR, the different interceptors could know nothing of each other.

回答11:

After reading the Gang of Four definitions, I'm not convinced there's a real difference. (included for convenience)

• Decorator: Allows for the dynamic wrapping of objects in order to modify their existing responsibilities and behaviours
• Chain of Responsibility: Gives more than one object an opportunity to handle a request by linking receiving objects together

Wikipedia fleshes them out a little, but some of it's kinda arbitrary.

• Decorator is typically implemented as a Linked List. But I think that's too low-level to be considered "part" of the pattern.
• Chain of Responsibility links only handle data if it's their responsibility; but determining responsibility and data handling are both part of behavior. Decorators can do this just as easily.
• Decorator requires you to call the delegate.
• A "pure" CoR link should only call the delegate if it doesn't handle the data.

The first two attributes don't really distinguish the patterns. The second two do, but the way Decorator and CoR are usually implemented don't enforce those attributes--the designer just hopes no one writes a Decorator that breaks the chain or a CoRLink that continues the chain after handling the data.

To actually implement these attributes, you'd need something like the following.

Enforced Decorator:

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
}

Enforced Chain of Responsibility:

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);
}

(Alternately, you could just add a line to the javadoc, if all you want is to absolve yourself of the responsibiity in case someone else screws up your design--but why leave it to chance?)