BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

Thoughts on "Chain of Responsibility" pattern

I've heard some criticism of the original GOF pattern "Chain of Responsibility" (COR).  Claims are made that the responsibility to move to the next object in the chain to handle any specific request should NOT be part of the objects themselves but rather part of a base class.

 

As I understand it, there is no inherent hierarchal object definition required for the classic COR pattern.  The COR is essentially a linked lists of objects, irrespective of where or how the individual objects are grouped.  We could theoretically have a COR with pointers to "Successor" present in completely disparate objects, right?

 

It seems to me wen taking the aforementioned criticism to heart, however, that applying COR to a Composite or a Decorator makes more sense in that the object hierarchy and the COR handler hierarchy are the same (and the abstract Decorator or Composite can then handle the chaining of request handlers).  Assuming this makes sense, I would further assume that a "Request" as defined in the COR Pattern would be typically implemented as a Command.  How then would one actually implement a suitable COR "Addressing" mechanism.  The ability to cast a command to a particular type would seem to be one aspect, but if a Composite or a Decorator has multiple elements of the same type of object, how to guarantee that the correct object handles the Command?

 

Or is this already gone past the scope of COR.   It quickly becomes a general hierarchal messenging system (accessors, methods and so on) for Composites or Decorators.  Have I missed something?

0 Kudos
Message 1 of 1
(4,531 Views)