Comments on: PTOM: The Decorator Pattern

By: gunasekaran sambandhan

gunasekaran sambandhan — Thu, 13 Sep 2012 07:11:00 +0000

@ guna

Great Article!
Very clean explaination of Decorator pattern. That forcing me to ask one question..
Q: It seems here this concept is violating one of the SOLID priniciple (
FUNCTIONS THAT USE … REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT. – Liskov Substitution Principle)

please correct me if i am wrong..

By: Ed

Ed — Tue, 18 Nov 2008 22:18:50 +0000

@ Brad Mead

Not really, the Head First Design Patterns book used the coffee example to illustrate the Decorator pattern.

@ schambers

You could have saved yourself the effort of writing this (otherwise good) post and just linked straight to the freely available chapter 3 of DHDP:

http://oreilly.com/catalog/hfdesignpat/chapter/ch03.pdf

By: schambers

schambers — Tue, 18 Nov 2008 08:29:04 +0000

@Pat

I suppose if your graph is that deep, then the easiest way to accomplish that is still with ABC’s for the base decorator.

This is a good question though. While I have not had decorators that were that complex heirarchy wise, I would be interested if anyone else has come across a situation like that.

By: Pat

Pat — Mon, 17 Nov 2008 19:50:38 +0000

Suppose your object model was a little more deep than just ICoffee:

ICoffee <- ILatte <- IX <- IY <- IZ

Whip cream, chocolate, etc. could only be added to IZ and not ICoffee directly. The decorator provides dynamic extensibility which is nice, but now something that decorates IZ has to also wrap all members of ICoffee, ILatte, IX, and IY.

If any aspect of that hierarchy changes, your decorator has to be updated. Does this present a maintenance issue? Are their ways to work around this?

By: Mike

Mike — Mon, 17 Nov 2008 19:46:13 +0000

Great post! very clear example, I posted about an example of employing decorator to add extra behaviour a while back http://journalofasoftwaredev.wordpress.com/2008/03/21/multi-search-engine-enhancement-using-design-patterns/ be interesting to see what you think

By: Brad Mead

Brad Mead — Mon, 17 Nov 2008 17:09:03 +0000

Good example… Thanks for a novel context (Coffee) in which to couch the understanding.

By: schambers

schambers — Mon, 17 Nov 2008 13:38:25 +0000

@Steve

I suppose you could say that is a concern, but an acceptable concern. You would need to contain the additional logic somewhere. One class per behavior would be acceptable in my eyes.

By: Steve

Steve — Mon, 17 Nov 2008 11:56:37 +0000

Excellent post – thank you for explaining the decorator pattern.

Question: is there concern of an ‘explosion of decorator classes’ ?

By: schambers

schambers — Mon, 17 Nov 2008 11:56:27 +0000

@Dave
The decorator is similar in behavior to the adapter pattern. The main difference being the intent of the adapter is to change one interface into another in order to be able to work with a system that you couldn’t normally work with.

While the structure is similar, the intent is different.

Thanks for the kind words!

By: Dave the Ninja

Dave the Ninja — Mon, 17 Nov 2008 05:34:04 +0000

I always think the decorator pattern is very similar to the Adapter pattern.

Both very very useful patterns.

Great article!

Dave the Ninja