So many pages on the internet attempt to explain a concept and then do so with an example that demonstrates a totally inappropriate use of the concept. I'd go s

So many pages on the internet attempt to explain a concept and then do so with an example that demonstrates a totally inappropriate use of the concept. I'd go so far as to say that the example is so bad that it no longer demonstrates the concept at all. The taco example is an example of an OOP antipattern. Its classic "naive OOP", i.e. "I can do this, so I should". If the taco where in an order taking system, a "menu item" object might have an associated list of "condiment" objects, and these would probably be associations to shared objects. If this were a video game, there might be separate behavioral and rendering objects, and the "rendering object" would simply be a number of generic models etc etc. I understand its hard to provide good examples when writing a blog, but this is precisely the situation when one should do so. To describe the decorator pattern and then provide examples that are bad to the point of misinformation is just lazy. The decorator pattern is already on sketchy ground IMHO. The wikipedia entry[1] says its to avoid separation of concerns issue, but it seems to do so by ignoring the IsA constraint. A WindowDecorator IsNotA Window. A DecoratedWindow might be a Window, and it might have a list of Decorators, but I can see all sorts of ways that a specific implementation will have a radically different class hierarchy. [1] https://en.wikipedia.org/wiki/Decorator_pattern https://en.wikipedia.org/wiki/Decorator_pattern