PHP计划模式（八）装饰器模式Decorator实例详解【布局型】

若你从事过面向工具开拓，实现给一个类或工具增进举动，行使担任机制，这是全部面向工具说话的一个根基特征。假如已经存在的一个类穷乏某些要领，可能需要给要领添加更多的成果（魅力），你大概会仅仅担任这个类来发生一个新类—这成立在特另外代码上。

通过担任一个现有类可以使得子类在拥有自身要领的同时还拥有父类的要领。可是这种要领是静态的，用户不能节制增进举动的方法和机缘。假如  你但愿改变一个已经初始化的工具的举动，你怎么办？可能，你但愿担任很多类的举动，改怎么办?前一个，只能在于运行时完成，后者显然时也许的，可是也许会导致发生大量的差异的类—可骇的工作。

你怎样组织你的代码使其可以轻易的添加根基的可能一些很罕用到的 特征，而不是直接不特另外代码写在你的类的内部？

装饰器模式： 动态地给一个工具添加一些特另外职责可能举动。就增进成果来说， Decorator模式对比天生子类更为机动。

装饰器模式提供了改变子类的机动方案。装饰器模式在不必改变原类文件和行使担任的环境下，动态的扩展一个工具的成果。它是通过建设一个包装工具，也就是装饰来包裹真实的工具。

当用于一组子类时，装饰器模式越发有效。假如你拥有一族子类（从一个父类派生而来），你必要在与子类独立行使环境下添加特另外特征，你可以行使装饰器模式，以停止代码一再和详细子类数目的增进。

以下环境行使Decorator模式

1)• 在不影响其他工具的环境下，以动态、透明的方法给单个工具添加职责。

2)• 处理赏罚那些可以除掉的职责。

3)• 当不能回收天生子类的要领举办扩充时。一种环境是，也许有大量独立的扩展，

为支持每一种组合将发生大量的子类，使得子类数量呈爆炸性增添。

另一种环境也许是由于类界说被潜匿，或类界说不能用于天生子类。

uml如图：

抽象组件脚色(Component)：界说一个工具接口，以类型筹备接管附加责任的工具，

即可以给这些工具动态地添加职责。

详细组件脚色(ConcreteComponent) :被装饰者，界说一个将要被装饰增进成果的类。

可以给这个类的工具添加一些职责

抽象装饰器(Decorator):维持一个指向构件Component工具的实例，

并界说一个与抽象组件脚色Component接口同等的接口

详细装饰器脚色（ConcreteDecorator):向组件添加职责。

装饰模式的特点：

　　（1） 装饰工具和真实工具有沟通的接口。这样客户端工具就可以以和真实工具沟通的方法和装饰工具交互。
　　（2） 装饰工具包括一个真实工具的索引（reference）
　　（3） 装饰工具接管全部的来自客户端的哀求。它把这些哀求转发给真实的工具。
　　（4） 装饰工具可以在转发这些哀求早年或往后增进一些附加成果。这样就确保了在运行时，不消修改给定工具的布局就可以在外部增进附加的成果。在面向工具的计划中，凡是是通过担任来实现对给定类的成果扩展。

     Decorator模式至少有两个首要利益和两个弱点：

1) 比静态担任更机动： 与工具的静态担任（多重担任）对比， Decorator模式提供了越发机动的向工具添加职责的方法。可以用添加和疏散的要领，用装饰在运行时候增进和删除职责。对比之下，担任机制要求为每个添加的职责建设一个新的子类。这会发生很多新的类，而且会增进体系的伟大度。另外，为一个特定的Component类提供多个差异的 Decorator类，这就使得你可以对一些职责举办殽杂和匹配。行使Decorator模式可以很轻易地一再添加一个特征。
2) 停止在条理布局高层的类有太多的特性 Decorator模式提供了一种“即用即付”的要领来添加职责。它并不试图在一个伟大的可定制的类中支持全部可预见的特性，相反，你可以界说一个简朴的类，而且用 Decorator类给它逐渐地添加成果。可以从简朴的部件组合出伟大的成果。这样，应用措施不必为不必要的特性支付价钱。同时更易于不依靠于 Decorator所扩展（乃至是不行预知的扩展）的类而独立地界说新范例的 Decorator。扩展一个伟大类的时辰，很也许会袒露与添加的职责无关的细节。
3) Decorator与它的Component纷歧样 Decorator是一个透明的包装。假如我们从工具标识的概念出发，一个被装饰了的组件与这个组件是有不同的，因此，行使装饰不该该依靠工具标识。
4) 有很多小工具 回收Decorator模式举办体系计划每每会发生很多看上去相同的小工具，这些工具仅仅在他们彼此毗连的方法上有所差异，而不是它们的类或是它们的属性值有所差异。尽量对付那些相识这些体系的人来说，很轻易对它们举办定制，可是很难进修这些体系，排错也很坚苦。

行使《php计划模式》内里的例子。

看看以下例子，你可以更好的领略这种概念。思量一个成立在组件观念上的“form”表单库，在哪里你必要为每一个你想要示意的表单节制范例成立一个类。这种类图可以如下所示：

Select and TextInput类是组件类的子类。若是你想要增进一个“labeled”带标签的组件—一个输入表单汇报你要输入的内容。由于任何一个表单都也许必要被标志，你也许会象这样担任每一个详细的组件：

上面的类图看起来并不怎么坏，下面让我们再增进一些特征。表单验证阶段，你但愿可以或许指出一个表单节制是否正当。你为犯科节制行使的代码又一次担任其余组件，因此又必要发生大量的子类：

这个类看起来并不是太坏，以是让我们增进一些新的成果。在布局有用性确认中你必要指出布局是否是有用的。你必要让你检讨有用性的代码也可以应用到其余部件，这样不消再更多的子类长举办有用性验证。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!