首页 > 代码库 > 设计模式——装饰者模式
设计模式——装饰者模式
1.装饰者模式是在不必改变原类文件和使用继承关系的情况下，动态地扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。
2.装饰模式的特点：
1) 装饰对象和真实对象有相同的接口。这样客户端对象就能以和真实对象相同的方式和装饰对象交互。
2) 装饰对象包含一个真实对象的引用
3) 装饰对象接受所有来自客户端的请求。它把这些请求转发给真实的对象
4) 装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运行时，不用修改给定对象的结构就可以在外部增加附加的功能。
3.设计原则：
1） 多用组合，少用继承：利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承相同的行为。然而，如果能够利用组合的做法扩展对象的行为，就可以在运行时动态的进行扩展
2） 遵守开闭原则。
4.适用性：
1） 需要扩展一个类的功能，或者给一个类添加附加职责。
2） 需要动态的给一个对象添加功能，这些功能可以再动态的撤销。
3） 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。
4） 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈现爆炸式增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。
5.优点：
1） 装饰者模式将各个功能独立出来，以组件的形式修饰一个对象，使得它比传统的继承更加灵活。
2） 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同的行为组合。
6.缺点：
1） 这种比继承更加灵活的特性，也同时意味着更加多的复杂性。
2） 装饰者模式会导致设计中产生许多小类（组件类），如果过度使用，会使程序变得很复杂。
3） 装饰者是针对抽象组件类型编程。但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否适合。当然也可以改变Component接口，增加新的公开行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。
7.装饰者模式角色：
1） 抽象组件角色：给出一个抽象接口，以规范准备接收附加责任的对象。
2） 具体组件角色：定义一个将要接收附加责任的类。
3） 装饰者抉择：持有一个组件对象实例，并实现一个与抽象构件接口一致的接口
4） 具体装饰者角色：负责将组件添加上附加责任
8.要点：
1） 装饰者和被装饰对象有相同的超类型
2） 可以用一个或多个装饰者包装一个对象
3） 装饰者可以在所委托被装饰者的行为之前或之后，加上自己的行为，以达到特定的目的。
4） 对象可以在任何时候被装饰，所以可以在运行时动态的，不限量的用你喜欢的装饰者来装饰对象
5） 装饰者模式中使用继承的关键是想达到装饰者和被装饰对象的类型匹配，而不是获得其行为。
6） 装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。在实际项目中可以根据需要为装饰者添加新的行为，做到“半透明”的装饰者。
7） 适配器模式的用意是改变对象的接口而不一定改变对象的性能，而装饰者模式用意是保留增加对象的职责。
9.装饰者模式结构图：
注意：以上实体组件，装饰者可以有好多。
代码示例：
Component：
定义一个对象接口，可以给这些对象动态地添加职责。
public interface Component
{
void operation();
}
Concrete Component：
定义一个对象，可以给这个对象添加一些职责。
public class ConcreteComponent implements Component
{
public voidoperation()
{
// Writeyour code here
}
}
Decorator：
维持一个指向Component对象的引用，并定义一个与 Component接口一致的接口。
public class Decorator implements Component
{
publicDecorator(Component component)
{
this.component= component;
}
public voidoperation()
{
component.operation();
}
private Componentcomponent;
}
Concrete Decorator：
在Concrete Component的行为之前或之后，加上自己的行为，以“贴上”附加的职责。
public class ConcreteDecorator extends Decorator
{
public voidoperation()
{
//addBehavior也可以在前面
super.operation();
addBehavior();
}
private voidaddBehavior()
{
//your code
}
}
10.模型简化：
1） 如果只有一个实体组件类，而没有抽象组件接口类时，可以让装饰者继承实体组件类
2） 如果只有一个实体装饰者类时，可以将装饰者和实体装饰者合并。
11.一个实际用例：
现在需要一个汉堡，主体是鸡腿堡，可以选择添加生菜、酱、辣椒等等许多其他的配料，这种情况下就可以使用装饰者模式。
汉堡基类：
packagedecorator;
publicabstract class Humburger {
protected String name ;
public String getName(){
return name;
}
public abstract double getPrice();
}
鸡腿堡类：
packagedecorator;
publicclass ChickenBurger extends Humburger {
public ChickenBurger(){
name = "鸡腿堡";
}
@Override
public double getPrice() {
return 10;
}
}
配料的基类
packagedecorator;
public abstractclass Condiment extends Humburger {
public abstract String getName();
}
生菜：
packagedecorator;
public classLettuce extends Condiment {
Humburger humburger;
public Lettuce(Humburger humburger){
this.humburger = humburger;
}
@Override
public String getName() {
returnhumburger.getName()+" 加生菜";
}
@Override
public double getPrice() {
returnhumburger.getPrice()+1.5;
}
}
辣椒：
packagedecorator;
public classLettuce extends Condiment {
Humburger humburger;
public Lettuce(Humburger humburger){
this.humburger = humburger;
}
@Override
public String getName() {
return humburger.getName()+"加生菜";
}
@Override
public double getPrice() {
returnhumburger.getPrice()+1.5;
}
}
测试：
packagedecorator;
public classLettuce extends Condiment {
Humburger humburger;
public Lettuce(Humburger humburger){
this.humburger = humburger;
}
@Override
public String getName() {
returnhumburger.getName()+" 加生菜";
}
@Override
public double getPrice() {
returnhumburger.getPrice()+1.5;
}
}
参考文献：
http://www.cnblogs.com/god_bless_you/archive/2010/06/10/1755212.html
http://baike.baidu.com/view/2787758.htm?fr=aladdin
http://blog.csdn.net/lansuiyun/article/details/11714957
本文出自 “虎哥的博客” 博客，请务必保留此出处http://7613577.blog.51cto.com/7603577/1587356
设计模式——装饰者模式