2

Please somebody clears me up the mess in my head with these patterns:

  • Chain of Command
  • Chain of Responsibility

I've seen sites in which both are the same (examples of Chain of Command which are the same as Chain of Responsibility), and other sites in which not.

This is what I understand about each:

CHAIN OF COMMAND:

A class let's call it CommandChain, with a property holding a list of "commands", which are instances of classes which implement the same interface. Say they all must implement onCommand(command, arguments).

CommandChain has the addCommand() method to register new commands within it, and runCommand() which accepts a command name, and its parameters. This method should loop through the list of commands until one of them responds, does the corresponding actions, and sends ok.

CHAIN OF RESPONSIBILITY

Just as I've seen in some sites, this would be pretty much the same, with this difference: instead of having a class storing a list of commands to loop through, each command instance would store a reference to the next command instance.

So, is this difference big enough to consider both design patterns different?

In what real cases are they applicable?

Luis Martin
  • 910
  • 3
  • 14
  • 31

3 Answers3

6

They are the same design pattern.

If they have the same properties and only the implementation differs, they are functionally the same. This indicates that the two design patterns are one and the same.

Another hint is that there is a Wikipedia page for Chain of Responsibility DP, but none for Chain of Command.

The "Gang of Four" who wrote the seminal book on DPs were very clear on that behavior and properties, not implementation, defined a design pattern.

Anders Johansen
  • 10,165
  • 7
  • 35
  • 52
  • They have the same behaviour after all, even though the 1st one stores the handlers in a property of a main class, and in the 2nd every handler contains the reference to the next one. I thought this might also be determinant to consider them different patterns. What implementation could be better, and as I asked Atul: in what usual cases in web development would this pattern be applicable? – Luis Martin Oct 04 '12 at 11:14
  • If the # of handlers tends to be fixed and known at the time they are set up, an implementation like the 1st one is preferable from a performance point of view, as you could then allocate the handlers as an array. This saves a pointer for the reference pr. handler. As for applicability of the pattern: Many, many cases. Usually when you want to have some default behavior (end of the chain, a catch-all handler) combined with several "special case" handlers. – Anders Johansen Oct 04 '12 at 11:53
1

It looks like that Chain of Command is used when there is a single handler that needs to perform multiple task based on some request while on the other hand in Chain of Responsibility is used when each handler can handle only one type of request. An example could be if there is fire alarm, there you can issue a request to fire-detecter which will instead issue many commands to check the fire at different levels or places. While who will be respond to this fire like fire-warden, security guard, police etc can be done by using chain-of-responsibility.

Atul
  • 1,694
  • 4
  • 21
  • 30
0

The Chain of Responsibility is one of the Gang of Four's original designs, and you can find several examples implemented in PHP here:

http://www.php5dp.com/category/design-patterns/chain-of-responsibility/

One use of the pattern has been with "sniffer" programs for selecting the correct device for use with Web sites that have multiple configurations for different devices (phone, tablet, desktop). The CoR pattern avoids coupling between the client making the request and the handling object.

It is not hierarchal in that one "handling object" is not above another, but it is sequential in that it goes through a set of options until it finds the most appropriate for a given request.

The "Chain of Command" may be a misnomer for the CoR or it may be a wholly different pattern with a hierarchal structure.

Bill
  • 95
  • 3