查看维基百科 (http://en.wikipedia.org/wiki/Decorator_pattern) 上的装饰器模式页面，布局看起来像这样：
装饰器是否可以直接实现组件接口（并跳过装饰器接口）？
【问题讨论】：
使用装饰器模式获得的主要好处是，对于客户端代码来说，它是透明的。他们不需要了解装饰器，只需将其视为基本接口的普通旧具体实现即可：
ThingDoer thingDoer = new ThingDoerDecorator(new AwesomeThingDoer());
ThingDoer otherThingDoer = new AwesomeThingDoer();
thingDoer.doThing();
otherThingDoer.doThing();
这只是可能的，因为装饰器实现了与它正在装饰的东西相同的接口。如果它不实现这个接口，你就会失去这个模式的大部分功能。
但是，有时有一个基础装饰器实现是有意义的。
abstract class BaseThingDoerDecorator implements ThingDoer {
private ThingDoer thingDoer;
protected BaseDecorator(ThingDoer thingDoer) {
this.thingDoer = thingDoer;
}
@Override
public void doThing() {
thingDoer.doThing();
}
}
现在可以做这样的事情了：
ThingDoer thingDoer = new BaseThingDoerDecorator(new AwesomeThingDoer()) {
@Override
public void doThing() {
System.out.println("This is an anonymous decorator");
super.doThing();
}
};
或者您可能希望所有装饰器都免受基础组件中的异常影响：
abstract class BaseThingDoerDecorator implements ThingDoer {
// Same as above...
// ...
@Override
public void doThing() {
try {
thingDoer.doThing();
} catch (Exception e) {
log(e);
}
}
}
【讨论】：
这是您引用的维基百科页面中的 UML 图：
在这个图中，装饰器不是一个接口，而是一个抽象类。组件在此图中也不是一个接口（因为从它继承的 ConcreteComponent 和 Decorator 类没有图中箭头的虚线）。我知道这是一个细节，但 UML 是特定的原因。
也就是说，任何 ConcreteDecorator 都可以直接从 Component 继承（或者如果您的设计使用接口，则实现其接口）而不使用 Decorator 抽象类。但是，所有ConcreteDecorator 需要聚合一个组件，因此如果您有多个ConcreteDecorator，抽象类可能有助于避免重复代码。
【讨论】：