>

若你从事过面向对象的php开发，即使很短的时间或者仅仅通过本书了解了一些，你会知道，你可以 通过继承改变或者增加一个类的功能，这是所有面向对象语言的一个基本特性。如果已经存在的一个php类缺少某些方法，或者须要给方法添加更多的功能（魅力），你也许会仅仅继承这个类来产生一个新类—这建立在额外的代码上。

但是产生子类并不总是可能或是合适的。如果  你希望改变一个已经初始化的对象的行为，你怎么办？或者，你希望继承许多类的行为，改怎么办?前一个，只能在于运行时完成，后者显然时可能的，但是可能会导致产生大量的不同的类—可怕的事情。

问题

你如何组织你的代码使其可以容易的添加基本的或者一些很少用到的 特性，而不是直接不额外的代码写在你的类的内部？

解决方案

装饰器模式提供了改变子类的灵活方案。装饰器模式允许你在不引起子类数量爆炸的情况下动态的修饰对象，添加特性。

当用于一组子类时，装饰器模式更加有用。如果你拥有一族子类（从一个父类派生而来），你需要在与子类独立使用情况下添加额外的特性，你可以使用装饰器模式，以避免代码重复和具体子类数量的增加。看看以下例子，你可以更好的理解这种观点。考虑一个建立在组件概念上的“form”表单库，在那里你需要为每一个你想要表现的表单控制类型建立一个类。这种类图可以如下所示：

Select and TextInput类是组件类的子类。假如你想要增加一个“labeled”带标签的组件—一个输入表单告诉你要输入的内容。因为任何一个表单都可能需要被标记，你可能会象这样继承每一个具体的组件：

上面的类图看起来并不怎么坏，下面让我们再增加一些特性。表单验证阶段，你希望能够指出一个表单控制是否合法。你为非法控制使用的代码又一次继承其它组件，因此又需要产生大量的子类：

这个类看起来并不是太坏，所以让我们增加一些新的功能。在结构有效性确认中你需要指出结构是否是有效的。你需要让你检验有效性的代码也可以应用到其它部件，这样不用再更多的子类上进行有效性验证。

这里子类溢出并不是唯一的问题。想一想那些重复的代码，你需要重新设计你的整个类层次。有没有更好的方法！确实，装饰器模式是避免这种情况的好方法。

装饰器模式结构上类似与代理模式（参见第2章）。一个装饰器对象保留有对对象的引用，而且忠实的重新建立被装饰对象的公共接口。装饰器也可以增加方法，扩展被装饰对象的接口，任意重载方法，甚至可以在脚本执行期间有条件的重载方法。

为了探究装饰器模式，让我们以前面讨论过的表单组件库为例，并且用装饰器模式而不是继承，实现“lable”和“invalidation”两个特性。