Hal: Any more benefits?

Ben: You don't run the risk that Decorators will override either a method of either the base class or one of the "inner" decorators.

Hal: I suppose that's something of a double-edged sword. Decorators do provide you with the ability to override their base class's methods while composition doesn't. You actually might want that.

Ben: You could, yes. And finally, with composition, you can easily remove an extra -something you can't do (or at least can't do easily) with Decorators.

Hal: Those are good points...

Ben: But you're unconvinced.

Hal: Well, I can see the benefits you've laid out, but I fundamentally don't like the idea that Coffee has to know about its extras. It seems that Coffee should only concern itself with itself - not with what might be added to or done with it. If Coffee has that responsibility, I worry that future needs will force me to alter the code for Coffee, rather than add a Decorator. That, for me, is a great benefit of using Decorators - the base class is only responsible for itself. It provides a layer of abstraction - and you know how I love abstractions. Now, you mentioned the case of an extra-hot coffee. In your scheme, would ExtraHot be a "CoffeeExtra" as you've defined it?

Ben: That does seem to be stretching things.

Hal:But a Decorator could handle it easily.

Ben: I agree: both patterns have their advantages and disadvantages. This example isn't a replacement for the Decorator pattern, but a different solution for this context.

Hal: Maybe that's the central point, Ben: when developers learn design patterns, they need to understand that they're not magic bullets. A pattern may be perfectly good in one context, but not well suited for another. I've seen developers force patterns into their code just for the sake of buzzword compliance.

Ben: Yeah, points will be deducted for gratuitous use of design patterns! Also, one pattern may just fit better with a developer's preferences. You're troubled by the idea that Coffee knows about its extras while it seems completely right to me that a Coffee should take on this responsibility. The point of learning design patterns isn't so that you can slavishly use them, but that you gain a wider perspective on how to solve problems in an elegant way that allows code to evolve gracefully.

Hal: So, one thing we can both agree to is that I'm right.

Ben: You said it: I'm right.