Forums Register Login

help: comparison between Decorator and Chain of Responsibility

+Pie Number of slices to send: Send
Hello,
I think there two design patterns are the same. Can anybody make a comparison.
Thanks a lot,
Denis
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
(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
+Pie Number of slices to send: Send
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.
And then the flying monkeys attacked. My only defense was this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 995 times.
Similar Threads
disable text box
Numeric Null Comparison
Iterations - finding the same value for 2 variables
Use of of a Comparable object as a parameter to indexof
Boxing confusion
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 23:54:40.