Why would I ever use a Chain of Responsibility over a Decorator?

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?

---

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.

---

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 ie 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

---

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.

链接地址: http://www.djcxy.com/p/76548.html

上一篇: 责任链的常见用法？

下一篇: 为什么我会用装饰者的责任链？