20

How Chain of Responsibility Pattern Differs from Decorator Pattern..?

Daniel Heilper
  • 1,182
  • 2
  • 17
  • 34
Mind Dead
  • 235
  • 1
  • 2
  • 7
  • 2
    Similiar discussion can be found here: http://stackoverflow.com/questions/747913/why-would-i-ever-use-a-chain-of-responsibility-over-a-decorator – hoymkot Jan 25 '13 at 02:09

2 Answers2

31

I generally think of the Decorator as "adding" to some thing, where as Chain of Responsiblity is more like handling something thing.

In comparing the two patterns (besides being apples and oranges) the biggest difference is the Chain of Responsibility can kill the chain at any point.

Think of decorators as a layered unit in which each layer always does pre/post processing. Chain of Responsibility is more like a linked list, and generally 1 thing handles processing.

The Chain of Responsibility pattern allows for multiple things to handle an event but it also gives them the opportunity to terminate the chain at any point.

Nix
  • 57,072
  • 29
  • 149
  • 198
  • Can you give me any scenario in what situations go for Chain of Responsibility or Decorator...? – Mind Dead Sep 15 '10 at 20:57
  • @Mind: Like Nix said, apples and oranges. Instead write what you are supposed to do and we can help you from there. – Marcus Nov 29 '10 at 14:38
  • I am confused as to why you are even comparing these seemingly very different paradigms in the first place? – Lost Crotchet Aug 25 '18 at 18:28
  • @Marcus Lets say you have a logging function. Now, here you would want to decorate the function because you'd want to execute the logging whether it succeeded or failed. On the flip side, lets say you want to create an object via some sort of builder. The builder function can be set through a chain, so that the entire building of the object can fail, if incase some thing broke. And chances are you don't really want to revert back to the original at the end. i.e chain pattern allows breaking. Decorator does not. PS:(I know I'm about a decade late, but I might as well add examples). – The 0bserver Aug 27 '20 at 11:09
  • With decorator calling base class you can perfectly terminate execution at certain decorator instance as well, so it doesn't differ from chain of command in this aspect. – Nickolodeon May 04 '23 at 08:17
16

Scenario:

Think of a service request ( typically Admin access to your laptop ), which needs to be approved by your Manager, Director and VP. In this case, Decorator pattern would just act as if at each level there would just be comments from each of them and finally you would get an output. So, Manager would say 'Approved and forwarded', Simlarly Director 'Ok Approved and forwarded' and finally VP 'Approved'. And your final output would be combination of all the 3 comments.

Note: the chain is not going to break no matter your request was approved or Disapproved.

In the Chain Of responsibility, at each stage the Individual person has the authority to Approve or Reject. And if at any level the request is rejected, then your request doesn't proceed to the next level, instead just terminates with the result. Hope this helps :)

RDX
  • 161
  • 1
  • 2
  • 1
    Nobody forbids certain decorator to not process any further. For example you could write in HRDecorator.ProcessApproval(...) { if (iApprove) { nextDecorator.ProcessApproval(...) } – Nickolodeon May 04 '23 at 08:19