设计模式---装饰模式
故事:穿什么有这么重要?
定义:
装饰模式:动态地给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更为灵活。
但是纯粹的装饰模式很难找到,大多数的装饰模式的实现都是“半透明”的,而不是完全透明的。换言之,允许装饰模式改变接口,增加新的方法。半透明的装饰模式是介于装饰模式和适配器模式之间的。适配器模式的用意是改变所考虑的类的接口,也可以通过改写一个或几个方法,或增加新的方法来增强或改变所考虑的类的功能。
大多数的装饰模式实际上是半透明的装饰模式,这样的装饰模式也称做半装饰、半适配器模式。
Component 是定义一个对象接口,可以给这些对象动态的添加职责。ConcreteComponent是定义一个具体的对象,也可以给这个对象添加一些职责。Decorator,装饰抽象类,继承了component,从外类来扩展component类的功能,但对于Component来说,是无需知道Decorator的存在的。至于ConcreteDecorator就是具体的装饰对象,起到给Component添加职责的功能。
针对的问题:
动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。不改变接口的前提下,增强所考虑的类的性能。
何时使用:
1)需要扩展一个类的功能,或给一个类增加附加责任。
2)需要动态的给一个对象增加功能,这些功能可以再动态地撤销。
3)需要增加一些基本功能的排列组合而产生的非常大量的功能,从而使继承变得 不现实。
实例:
咖啡是一种饮料,咖啡的本质是咖啡豆+水磨出来的。咖啡店现在要卖各种口味的咖啡,如果不使用装饰模式,那么在销售系统中,各种不一样的咖啡都要产生一个类,如果有4中咖啡豆,5种口味,那么将要产生至少20个类(不包括混合口味),非常麻烦。使用了装饰模式,只需要11个类即可生产任意口味咖啡(包括混合口味)。
Beverage饮料接口
/** * 饮料接口 * @author Administrator * */ public interface Beverage { //返回商品描述 public String getDescription(); //返回价格 public double getPrice(); }
CoffeeBean1——具体被装饰的对象类1
public class CoffeeBean1 implements Beverage { private String description = "选了第一种咖啡豆"; @Override public String getDescription() { return description; } @Override public double getPrice() { return 50; } }
CoffeeBean2——具体被装饰的对象类2
public class CoffeeBean2 implements Beverage { private String description = "第二种咖啡豆!"; @Override public String getDescription() { return description; } @Override public double getPrice() { return 100; } }
Decorator——装饰类
public class Decorator implements Beverage { private String description = "我只是装饰器,不知道具体的描述"; @Override public String getDescription() { return description; } @Override public double getPrice() { return 0; //价格由子类来决定 } }
Milk——具体装饰类,给咖啡加入牛奶
public class Milk extends Decorator{ private String description = "加了牛奶!"; private Beverage beverage = null; public Milk(Beverage beverage){ this.beverage = beverage; } public String getDescription(){ return beverage.getDescription()+"\n"+description; } public double getPrice(){ return beverage.getPrice()+20; //20表示牛奶的价格 } }
Mocha——给咖啡加入摩卡
public class Mocha extends Decorator { private String description = "加了摩卡!"; private Beverage beverage = null; public Mocha(Beverage beverage){ this.beverage = beverage; } public String getDescription(){ return beverage.getDescription()+"\n"+description; } public double getPrice(){ return beverage.getPrice()+49; //30表示摩卡的价格 } }
Soy——给咖啡加入豆浆
public class Soy extends Decorator { private String description = "加了豆浆!"; private Beverage beverage = null; public Soy(Beverage beverage){ this.beverage = beverage; } public String getDescription(){ return beverage.getDescription()+"\n"+description; } public double getPrice(){ return beverage.getPrice()+30; //30表示豆浆的价格 } }
测试类:
public class Test { public static void main(String[] args) { Beverage beverage = new CoffeeBean1(); //选择了第一种咖啡豆磨制的咖啡 beverage = new Mocha(beverage); //为咖啡加了摩卡 beverage = new Milk(beverage); System.out.println(beverage.getDescription()+"\n加了摩卡和牛奶的咖啡价格:"+beverage.getPrice()); } }
测试结果:
装饰模式和适配器模式的关系:
装饰模式和适配器模式都是“包装模式(Wrapper Pattern)”,它们都是通过封装其他对象达到设计的目的的,但是它们的形态有很大区别。
理想的装饰模式在对被装饰对象进行功能增强的同时,要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。而适配器模式则不然,一般而言,适配器模式并不要求对源对象的功能进行增强,但是会改变源对象的接口,以便和目标接口相符合。
装饰模式有透明和半透明两种,这两种的区别就在于装饰角色的接口与抽象构件角色的接口是否完全一致。透明的装饰模式也就是理想的装饰模式,要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。相反,如果装饰角色的接口与抽象构件角色接口不一致,也就是说装饰角色的接口比抽象构件角色的接口宽的话,装饰角色实际上已经成了一个适配器角色,这种装饰模式也是可以接受的,称为“半透明”的装饰模式,如下图所示。
在适配器模式里面,适配器类的接口通常会与目标类的接口重叠,但往往并不完全相同。换言之,适配器类的接口会比被装饰的目标类接口宽。
显然,半透明的装饰模式实际上就是处于适配器模式与装饰模式之间的灰色地带。如果将装饰模式与适配器模式合并成为一个“包装模式”的话,那么半透明的装饰模式倒可以成为这种合并后的“包装模式”的代表。
优点:
(1)装饰模式与继承关系的目的都是要扩展对象的功能,但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”一个需要的“装饰”,或者除掉一个不需要的“装饰”。继承关系则不同,继承关系是静态的,它在系统运行前就决定了。
(2)通过使用不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为的组合。
缺点:
使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难,特别是这些对象看上去都很相像。