装饰者跟被装饰者之间没有任何继承关系，“装饰者模式”官方的解释就是这个意思，只是通过组合来扩展对象的职责。如果正常情况下，我们肯定是用继承来解决灯具的装饰问题，有多少了灯具都继承自灯泡类，但是通过这种包含的方式就绕开了继承带来的耦合问题。上面的代码还远远没有完成，我们来看后面会出现什么样的问题。
模式灯具的效果：
|
|
从上面的灯具例子来看，我们基本上完成了装饰者模式的模拟。但是这样的代码扩展性太差，设计模式所提倡面向接口编程，而我们这里似乎没有看见接口。例子中的所有代码都是直接使用对象的名称，这样肯定是耦合的。我们继续延伸问题，来解决你刚开始开文章的困境，抽象类、接口、继承跑哪去了。总觉得例子的代码太简单了，哪像是设计模式啊。别急我们继续讨论，设计模式本来就是思想性的理论，需要耐心的研究。
我们的灯泡是实体类而不是抽象类，这就说明我们的灯泡设计是不合理的，我们假如灯泡是个半成品，这个半成品是不能直接用的，任何装饰者都需要经过一定的修改才能使用。所以这样一来，我们的灯泡类就是抽象的了；
那为什么需要用装饰者来继承被装饰者呢，其实很简单原因就是没有统一的接口。我们假如灯泡只能用一种方式打开，任何灯具都不能擅自修改这统一的接口。因为这接口是灯泡厂商规定的，比如一些电流、电压、线路原理等等都是不允许直接修改的。只有继承自装饰者对象我才能够使用被装饰者的约定，比如一个方法的名称、一个属性的名称。而我们在使用的时候完全是使用被装饰者的方式在使用，这样就破快了约定。
