http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Stan: I'm not sure how dynamic proxy or using PostSharp is different. OK, you don't write decorator by hand but still something is decorating object. Runtime behaviour is same.http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment9http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment9Thu, 08 Nov 2012 18:03:05 GMT@Ayende: That's exactly one of the differences between Proxy and Decorator: In a decorator behaviour is added with the API of the underlying object in mind. So if that API changes, the decorator has to be modified as well. In a proxy on the other hand, you have a one-size-fits-all approach, i.e. adding the same functionality to every method of the underlying object. Consequently, proxies can be constructed dynamically in many languages, usually employing reflection.http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment8http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment8Thu, 08 Nov 2012 08:25:13 GMTDecorator can be usefull in c++ with its multiple inheritance. For c# it's mostly useless for reasons Ayende have provided. Something like dynamic proxy or post sharping may be better used for injecting behaviour.http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment7http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment7Thu, 08 Nov 2012 06:38:47 GMTEuphoric, That is certainly one aspect of that. The other aspect is that when you add a new method to the decorated object, you now need to go and add that to all the decorating, etc. I don't like this sort of behavior.http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment6http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment6Wed, 07 Nov 2012 23:49:40 GMTDecorator plays especially nicely with DI containers and cross cutting concerns. StructureMap's Interceptor API just screams decorator at you. http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment5http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment5Wed, 07 Nov 2012 21:29:37 GMTditto re the CachingDecorator. What is wrong with it?http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment4http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment4Wed, 07 Nov 2012 19:58:30 GMT@Michal : I think one reasons are side effects. This decorator would need to know if underlying data/decorated object changed and invalidate itself. This introduces hard to debug problems when cache decorator returns invalid data. I think this is what having one input/output channel means.http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment3http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment3Wed, 07 Nov 2012 19:58:29 GMTCould you please specify more, why we should avoid CachingDecorator? Actually I thought that it was very elegant solution to do caching and work with DI container.http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment2http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment2Wed, 07 Nov 2012 16:02:10 GMTIs that code example from Head First Design Patterns? I found that book's examples to not always be very motivating--that is, they demonstrated use of a pattern, but not necessarily a case where you'd actually want to use that pattern.http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment1http://ayende.com/159553/design-patterns-in-the-test-of-time-decorator#comment1Wed, 07 Nov 2012 13:03:26 GMT