装饰模式
装饰模式能够实现动态的为对象添加功能，是从一个对象外部来给对象添加功能。通常有两种方式可以实现给一个类或对象增加行为：
- 继承机制，使用继承机制是给现有类添加功能的一种有效途径，通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法。但是这种方法是静态的，用户不能控制增加行为的方式和时机。
- 组合机制，即将一个类的对象嵌入另一个对象中，由另一个对象来决定是否调用嵌入对象的行为以便扩展自己的行为，我们称这个嵌入的对象为装饰器(Decorator)
显然，为了扩展对象功能频繁修改父类或者派生子类这种方式并不可取。在面向对象的设计中，我们应该尽量使用对象组合，而不是对象继承来扩展和复用功能。装饰器模式就是基于对象组合的方式，可以很灵活的给对象添加所需要的功能。装饰器模式的本质就是动态组合。动态是手段，组合才是目的。总之，装饰模式是通过把复杂的功能简单化，分散化，然后在运行期间，根据需要来动态组合的这样一个模式。
装饰模式定义
装饰模式(Decorator Pattern) ：动态地给一个对象增加一些额外的职责(Responsibility)，就增加对象功能来说，装饰模式比生成子类实现更为灵活。其别名也可以称为包装器(Wrapper)，与适配器模式的别名相同，但它们适用于不同的场合。根据翻译的不同，装饰模式也有人称之为“油漆工模式”，它是一种对象结构型模式。
装饰模式的优点
- 装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
- 可以通过一种动态的方式来扩展一个对象的功能，通过配置文件可以在运行时选择不同的装饰器，从而实现不同的行为。
- 通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合。可以使用多个具体装饰类来装饰同一对象，得到功能更为强大的对象。
模式结构和说明
模式结构说明图.jpg
- 聚合关系用一条带空心菱形箭头的直线表示，上图表示Component聚合到Decorator上，或者说Decorator由Component组成。
- 继承关系用一条带空心箭头的直接表示
- 看懂UML类图和时序图
这里不会将UML的各种元素都提到，我只想讲讲类图中各个类之间的关系； 能看懂类图中各个类之间的线条、箭头代表什么意思后，也就足够应对 日常的工作和交流； 同时，我们应该能将类图所表达的含义和最终的代码对应起来； 有了这些知识，看后面章节的设计模式结构图就没有什么问题了；
本章所有图形使用Enterprise Architect 9.2来画,所有示例详见根目录下的design_patterns.EAP
从一个示例开始
请看以下这个类图，类之间的关系是我们需要关注的：
_images/uml_class_struct.jpg
- 车的类图结构为<<abstract>>，表示车是一个抽象类；
- 它有两个继承类：小汽车和自行车；它们之间的关系为实现关系，使用带空心箭头的虚线表示；
- 小汽车为与SUV之间也是继承关系，它们之间的关系为泛化关系，使用带空心箭头的实线表示；
- 小汽车与发动机之间是组合关系，使用带实心箭头的实线表示；
- 学生与班级之间是聚合关系，使用带空心箭头的实线表示；
- 学生与身份证之间为关联关系，使用一根实线表示；
- 学生上学需要用到自行车，与自行车是一种依赖关系，使用带箭头的虚线表示；
下面我们将介绍这六种关系；
类之间的关系
泛化关系(generalization)
类的继承结构表现在UML中为：泛化(generalize)与实现(realize)：
继承关系为 is-a的关系；两个对象之间如果可以用 is-a 来表示，就是继承关系：（..是..)
eg：自行车是车、猫是动物
泛化关系用一条带空心箭头的直接表示；如下图表示（A继承自B）；
_images/uml_generalization.jpg
eg：汽车在现实中有实现，可用汽车定义具体的对象；汽车与SUV之间为泛化关系；
_images/uml_generalize.jpg
注：最终代码中，泛化关系表现为继承非抽象类；
实现关系(realize)
实现关系用一条带空心箭头的虚线表示；
eg：”车”为一个抽象概念，在现实中并无法直接用来定义对象；只有指明具体的子类(汽车还是自行车)，才 可以用来定义对象（”车”这个类在C++中用抽象类表示，在JAVA中有接口这个概念，更容易理解）
_images/uml_realize.jpg
注：最终代码中，实现关系表现为继承抽象类；
聚合关系(aggregation)
聚合关系用一条带空心菱形箭头的直线表示，如下图表示A聚合到B上，或者说B由A组成；
_images/uml_aggregation.jpg
聚合关系用于表示实体对象之间的关系，表示整体由部分构成的语义；例如一个部门由多个员工组成；
与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在；例如， 部门撤销了，人员不会消失，他们依然存在；
组合关系(composition)
组合关系用一条带实心菱形箭头直线表示，如下图表示A组成B，或者B由A组成；
_images/uml_composition.jpg
与聚合关系一样，组合关系同样表示整体由部分构成的语义；比如公司由多个部门组成；
但组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也不存在了；例如， 公司不存在了，部门也将不存在了；
关联关系(association)
关联关系是用一条直线表示的；它描述不同类的对象之间的结构关系；它是一种静态关系， 通常与运行状态无关，一般由常识等因素决定的；它一般用来定义对象之间静态的、天然的结构； 所以，关联关系是一种“强关联”的关系；
比如，乘车人和车票之间就是一种关联关系；学生和学校就是一种关联关系；
关联关系默认不强调方向，表示对象间相互知道；如果特别强调方向，如下图，表示A知道B，但 B不知道A；
_images/uml_association.jpg
注：在最终代码中，关联对象通常是以成员变量的形式实现的；
依赖关系(dependency)
依赖关系是用一套带箭头的虚线表示的；如下图表示A依赖于B；他描述一个对象在运行期间会用到另一个对象的关系；
_images/uml_dependency.jpg
与关联关系不同的是，它是一种临时性的关系，通常在运行期间产生，并且随着运行时的变化； 依赖关系也可能发生变化；
显然，依赖也有方向，双向依赖是一种非常糟糕的结构，我们总是应该保持单向依赖，杜绝双向依赖的产生；
注：在最终代码中，依赖关系体现为类构造方法及类方法的传入参数，箭头的指向为调用关系；依赖关系除了临时知道对方外，还是“使用”对方的方法和属性；
时序图
为了展示对象之间的交互细节，后续对设计模式解析的章节，都会用到时序图；
时序图（Sequence Diagram）是显示对象之间交互的图，这些对象是按时间顺序排列的。时序图中显示的是参与交互的对象及其对象之间消息交互的顺序。
时序图包括的建模元素主要有：对象（Actor）、生命线（Lifeline）、控制焦点（Focus of control）、消息（Message）等等。
关于时序图，以下这篇文章将概念介绍的比较详细；更多实例应用，参见后续章节模式中的时序图；
http://smartlife.blog.51cto.com/1146871/284874
附录
在EA中定义一个抽象类（其版型为《abstract》)
_images/uml_AbatractClass.jpg
Component：组件对象的接口，可以给这些对象动态的添加职责；
ConcreteComponent：具体的组件对象，实现了组件接口。该对象通常就是被装饰器装饰的原始对象，可以给这个对象添加职责；
Decorator：所有装饰器的父类，需要定义一个与Component接口一致的接口(主要是为了实现装饰器功能的复用，即具体的装饰器A可以装饰另外一个具体的装饰器B，因为装饰器类也是一个Component)，并持有一个Component对象，该对象其实就是被装饰的对象。如果不继承Component接口类，则只能为某个组件添加单一的功能，即装饰器对象不能再装饰其他的装饰器对象。
ConcreteDecorator：具体的装饰器类，实现具体要向被装饰对象添加的功能。用来装饰具体的组件对象或者另外一个具体的装饰器对象。
装饰器的示例代码
1.Component抽象类, 可以给这些对象动态的添加职责
abstract class Component
{
abstract public function operation();
}
2.Component的实现类
class ConcreteComponent extends Component
{
public function operation()
{
echo __CLASS__ . '|' . __METHOD__ . "\r\n";
}
}
3.装饰器的抽象类，维持一个指向组件对象的接口对象， 并定义一个与组件接口一致的接口
abstract class Decorator extends Component
{
/**
* 持有Component的对象
*/
protected $component;
/**
* 构造方法传入
*/
public function __construct(Component $component)
{
$this->component = $component;
}
abstract public function operation();
}
4.装饰器的具体实现类，向组件对象添加职责，beforeOperation()，afterOperation()为前后添加的职责。
class ConcreteDecoratorA extends Decorator
{
//在调用父类的operation方法的前置操作
public function beforeOperation()
{
echo __CLASS__ . '|' . __METHOD__ . "\r\n";
}
//在调用父类的operation方法的后置操作
public function afterOperation()
{
echo __CLASS__ . '|' . __METHOD__ . "\r\n";
}
public function operation()
{
$this->beforeOperation();
$this->component->operation();//这里可以选择性的调用父类的方法，如果不调用则相当于完全改写了方法，实现了新的功能
$this->afterOperation();
}
}
class ConcreteDecoratorB extends Decorator
{
//在调用父类的operation方法的前置操作
public function beforeOperation()
{
echo __CLASS__ . '|' . __METHOD__ . "\r\n";
}
//在调用父类的operation方法的后置操作
public function afterOperation()
{
echo __CLASS__ . '|' . __METHOD__ . "\r\n";
}
public function operation()
{
$this->beforeOperation();
$this->component->operation();//这里可以选择性的调用父类的方法，如果不调用则相当于完全改写了方法，实现了新的功能
$this->afterOperation();
}
}
5.客户端使用装饰器
class Client
{
public function main()
{
$component = new ConcreteComponent();
$decoratorA = new ConcreteDecoratorA($component);
$decoratorB = new ConcreteDecoratorB($decoratorA);
$decoratorB->operation();
}
}
$client = new Client();
$client->main();
6.运行结果
oncreteDecoratorB|ConcreteDecoratorB::beforeOperation
ConcreteDecoratorA|ConcreteDecoratorA::beforeOperation
ConcreteComponent|ConcreteComponent::operation
ConcreteDecoratorA|ConcreteDecoratorA::afterOperation
ConcreteDecoratorB|ConcreteDecoratorB::afterOperation
装饰模式需要注意的问题
- 一个装饰类的接口必须与被装饰类的接口保持相同，对于客户端来说无论是装饰之前的对象还是装饰之后的对象都可以一致对待。
- 尽量保持具体组件类ConcreteComponent的轻量，不要把主逻辑之外的辅助逻辑和状态放在具体组件类中，可以通过装饰类对其进行扩展。 如果只有一个具体组件类而没有抽象组件类，那么抽象装饰类可以作为具体组件类的直接子类。
适用环境
- 需要在不影响组件对象的情况下，以动态、透明的方式给对象添加职责。
- 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时可以考虑使用装饰类。
网友评论