In the GoF you will see that:
Decorator inherits from
Component in order to offer the same interface
Decorator uses composition of a
Component object in order to be able to dynamically decorate/undecorate a component.
Decorator therefore implements all the methods of the
Component interface by forwarding the call to the component.
In other words, the
Decorator is not just an interface: it’s a real class that is responsible of holding the component reference and forward the calls to the base-class methods. In principle, all its methods should be implemented. It is therefore not “abstract” in the sense that there would be missing implementation details, but only conceptually abstract, meaning that it’s supposed to be extended by concrete decorators.
If the enrichment is simple, there is indeed no need to add this abstract decorator class. The GoF points this out in the discussion about implementation issues:
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
responsibility for forwarding requests to the component into the
I nevertheless would be reluctant to get rid of this middleman, especially if there could be a lot of method-calls to forward (i.e. base class methods that are not supposed to be changed by a decorator): the abstract decorator prevents a lot of repetitions of boilerplate code in the concrete decorators.
Minor remark: The example on which you work is somewhat confusing, since the component itself has a
decorate() method, which could mislead to think that this has something to do with the decorator. In addition, despite the many concrete decorators, it misses the opportunity to show that new responsibilities could also be added to a decorator.