• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

help: comparison between Decorator and Chain of Responsibility

 
Denis Wang
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
I think there two design patterns are the same. Can anybody make a comparison.
Thanks a lot,
Denis
 
Nishant Anshul
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I disagree Dennis. Perhaps not even remote semblance between decorator and chn of responsibility. To some extent chain of responsibility is close to command pattern.
Plz refer to GOF book. Just one point i would like to add here. Decorator 'D' will never change the interface 'I' on which it is applied. That means if 'D' is applied to 'I' to give u 'I1', the old 'I' is still valid and reusable in same system. Thus it adds some behaviour dynamically. Chain of responsibility implies u are never sure which object will trap ur request. It is open ended. U r not even sure of perhaps how many probable receivers can be there.
 
Denis Wang
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(1)
Assume I have a idiot design pattern, which is named as
additionalFunctionality. I have two data structures: one is an set (or array if you like); the other is a link list.
Then in a nutshell:
decorator = additionalFunctionality implemented in a set data
structure.
chain of responsibility = additionalFunctionality implemented in a
link list data structure.
(2)
I just don't get it whether one is structural design pattern and the
other behavioral.
Please make comments on statement(1) and question(2) as above.
Thanks,
Best regards,
Denis
 
Nishant Anshul
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good, it's a fresh example...okay..so we have a Set and a LinkedList. On a parent data structure, if we have got a 'set' now, it means we have changed the data structure and possibly eliminated the duplicate ones to get a 'Set'. To get a linkedlist, we have changed the data structure to get a list(ordered coll) and then added extra fucntions like getting elements from end or begining. 'Set' here will just be an inheritance example. To some extent, linkedlist can be called decorator if u consider a LinkedList class typed over a list interface. But remember its still a static inheritance, so not a very good case for decorator. This is just my opinion and i respect ur right to disagree.
2)Both Structural and behavioral patterns can be static or dynamic. Decorator is still structural bcz we are not changing the behaviour of obj at run-time, we r giving it some extra responsiblity to do. So we say that the structure of object is changed to suit the extra responsibilities.e.g may be we have to add an internal buffer with the object to support buffering...still a structural pattern.
In chain of resp, we say that whichever obj want to be a part of this chain, it needs to implement some func ..and so if CONDITION IS MET..it
will have the responsibility to trap the request. So whenever some communication between objects is there, its a healthy indicator of behavioral pattern. 'request' being comm obj in this case.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic