Decorator pattern: Why do we need an abstract decorator?

Better one and a half year late than never:

A base class for decorators of a certain interface is not necessary.

However, it is very useful to have:

• for one thing, as a means of documenting that classes derived from it are decorators of the interface in question

• but mostly, because decorators usually do not need to add functionality to every single method of the decorated interface.

So, a base decorator class allows derived decorators to implement only those methods of the interface to which they actually need to add some functionality, leaving the rest of the methods to the base class to provide a default implementation for. (Which simply delegates the call to the decoree.)

Contrast this with writing decorators that implement the decorated interface from scratch, where the compiler requires that you provide an implementation for every single method of the interface, whether your decorator will be adding any functionality to it, or not.

It is that simple, really.

I was wondering the same thing. Going back to the source, GOF Design Patterns, I see this under 'Implementation' in the Decorator chapter:

"Omitting the abstract Decorator class. There's no need to define an abstract Decorator class when you only need to add one responsibility. That's often the case when you're dealing with an existing class hierarchy rather than designing a new one. In that case, you can merge Decorator's responsilibility for forwarding requests to the component into the Concrete Decorator."

So at least in that case, it seems that GOF agree with you :-)

I'm not sure what the meaning of 'one responsibility' is. I'm not sure if more than 'one responsibility' would mean one concrete decorator that has more than one responsibility or more than one concrete decorator, each with its one responsibility. Either way, I don't see why the abstract Decorator is necessary. My guess is that tvanfosson's answer (in his comment on his own answer) is the right one - that once you start creating a number of decorating classes, it clarifies the design decision to group them under a superclass. On the other hand, where there is just one class, it perhaps makes the design decision less clear if you add in a second class that just sits as a pointless middle-man between base component and decorator (having said that, it's fairly likely that you'll want to add more at some point, so maybe better to include the abstract decorator even in the single case...)

At any rate, seems like it's to do with making the design clear, rather than the being the difference between the code working and not.

(A bit late to your question..)

I also spent quite a while to try to figure out an answer. In my case the non-concrete Decorator extends the class to be decorated ("decoree"), instead of an interface common to both the decoree and the Decorator.

After reading from different sources, it seems to me that, besides what tvanfosson said, the reason to have the concrete decorators extend an abstract, or more general, decorator is so that we don't repeat the "delegation" code over and over again.

[Beverage]<———————[(abstract) CondimentDecorator]<—————[Milk]
[decoree ]——————<>[ adds code to efficiently    ]
                  [ forward calls to decorated  ]<—————[LemonJuice]
                  [ instance of Beverage        ]

In your case, your abstract decorator would extend the decoree and would implement the same interface as the decoree, delegating/forwarding all method calls to it. Then, the concrete decorators that you may build, would only need to implement those methods where you would want to do something different than just forward the method call to the decoree.

I hope I was clear.. :-S

Personally, I'm a bit disappointed at the need to repeat the decoree's interface in the decorator. This adds some coupling, since any time the decoree's interface changes (like getting more methods), the decorator needs to catch up.

In PHP 5.3.2 (yes, I know your question is related to Java), though, it should be possible to dynamically catch all method calls and forward them all, without the Decorator needing to know which methods are being called (in a not a very efficient way, though, having to use the Reflection API). I guess this is possible in Ruby and other languages already.

PS: This is my first answer ever in SO! ^_^