摘要：本文深入浅出的讲述了设计模式中的装饰模式
,
并给出了简单的示例
,
例子浅显易懂
,
并附带源代码。
装饰模式属于结构型模式。意图是动态地给一个对象添加一些额外的职责，就增加功能来说，Decorator模式相比生成子类更为灵活。Decorator模式又叫包装器模式。打个比方说，一个相片被嵌入相框，这个相框就使一个装饰，目的是使得相片看起来更美观大方，这里就使用了装饰模式，如果在相片洗出来之前添加一个相框的图片，这样看起来和添加一个相框没有什么区别，对于原来的相片而言，这就有点类似于继承。
在程序中，将组件嵌入另一个对象中，由这个对象添加边框，我们称这个嵌入的对象为装饰，这个装饰与他所装饰的组件接口一致，因此它对使用该组件的客户透明。他将客户请求转发给该组件，并且可能在转发前和转发后执行一些额外的动作。透明性使得你可以递归的嵌套多个装饰，从而可以添加任意多的功能。
适用性：
l
在不影响其他对象的情况下，以动态透明的方式给单个对象添加职责
图
1
装饰模式例子
UML
图
在本例子中有一个组件的接口，具体组件和装饰者都实现了组件的接口，装饰模式的主要目的是为目标增建功能，因此，在
Decorator
类中包含了一个指向被装饰组建的对象，在装饰者
Decorator
的
getName
方法中返回了一个带有装饰效果的
String
对象，原来的返回结果可能是一个没有包含任何修饰符号，而经过装饰之后，返回的
String
包含了
++Str++
类似的效果，我们说
Decorator
装饰了
Component.
参与者：
Component:
定义一个对象接口，可以给这些对象动态的添加职责。
ConcreteComponent:
定义一个对象可以给这个对象动态的添加职责。
Decorator:
维护一个指向
Component
对象的指针，并定义一个与
Component
接口一致的接口
,
或者直接实现
Component
对象。
协作关系：
Decorator
把来自客户端的请求发送给所装饰的
ConcreteComponent,
在发送请求的前后执行一些附加的动作。
Decorator
模式有以下的优缺点：
1.
比静态继承更灵活
与对象的静态继承相比，
Decorator
模式提供了更加灵活的向对象添加职责的方式，可以使用添加和分离的方法，用装饰在运行时刻增加和删除职责。使用继承机制增加职责需要创建一个新的子类，如果需要为原来所有的子类都添加功能的话，每个子类都需要重写，增加系统的复杂度，此外可以为一个特定的
Component
类提供多个
Decorator
，这种混合匹配是适用继承很难做到的。
2.
避免在层次结构高层的类有太多的特征，
Decorator
模式提供了一种“即用即付”的方法来添加职责，他并不试图在一个复杂的可订制的类中支持所有可预见的特征，相反可以定义一个简单的类，并且用
Decorator
类给他逐渐的添加功能，可以从简单的部件组合出复杂的功能。
3.
Decorator
与它的
Component
不一样
Decorator
是一个透明的包装，如果我们从对象标识的观点出发，一个被装饰了的组件与这个组件是有差别的，因此使用装饰时不应该以来对象标识。
4.
产生许多小对象，采用
Decorator
模式进行系统设计往往会产生许多看上去类似的小对象，这些对象仅仅在他们相互连接的方式上有所不同。
类的相关代码：
package decorator;
public
interface
Component{
public
void
setName(String aName);
public
String getName();
}
ConcreteComponent
代码：
package
decorator;
public
class
ConcreteComponent
implements
Component{
String
name
;
public
void
setName(String aName){
name
= aName;
}
public
String getName(){
return
name
;
}
}
Decorator
代码：
package
decorator;
public
class
Decorator
implements
Component{
private
Component
component
;
public
Decorator(Component c){
component
= c;
}
public
void
setName(String aName){
component
.setName(aName);
}
public
String getName(){
return
"Name :"
+
component
.getName();
}
}
Client
代码
package
decorator;
public
class
Client {
public
static
void
main(String[] args){
Component c=
new
ConcreteComponent();
Component d =
new
Decorator(c);
c.setName(
"Lili"
);
System.
out
.println(c.getName());
d.setName(
"Lili"
);
System.
out
.println(d.getName());
}
}
这些代码显示了使用装饰模式之后同样的请求却又有不同的结果。
总结：在为对象添加职责时，适用装饰模式比静态继承要节省很多。如果有
3
个子类，每个类有另外的两种职责，可能要写
2*3=6
个子类，如果使用装饰模式
之需要
2
个就可以了。
。
l
处理那些可以撤销的职责。
l
当不能采用生成子类的方法进行扩充时，一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类的树木呈爆炸性增长，另一种可能是因为定义被隐蔽或类定义不能用于生成子类。
本文转自凌辉博客51CTO博客，原文链接http://blog.51cto.com/tianli/35287如需转载请自行联系原作者
lili00okok
