装饰者模式
定义:指在不改变现有对象结构的情况下,动态地给该对象增加一些指责(即增加其额外功能)的模式,它属于对象结构型模式。
- 装饰器是继承的有力补充,比继承灵活,在不改变原有对象的情况下,动态的给一个对象扩展功能,即插即用
- 通过使用不用装饰类及这些装饰类的排列组合,可以实现不同效果
- 装饰器模式完全遵守开闭原则
其主要缺点是:装饰器模式会增加许多子类,过度使用会增加程序得复杂性。
模式的结构
装饰器模式主要包含以下角色。
- 抽象构件(Component)角色:定义一个抽象接口以规范准备接收附加责任的对象。
- 具体构件(ConcreteComponent)角色:实现抽象构件,通过装饰角色为其添加一些职责。
- 抽象装饰(Decorator)角色:继承抽象构件,并包含具体构件的实例,可以通过其子类扩展具体构件的功能。
- 具体装饰(ConcreteDecorator)角色:实现抽象装饰的相关方法,并给具体构件对象添加附加的责任。
装饰器模式的结构图如图所示:
案例
星巴克咖啡订单项目(咖啡馆):
1)咖啡种类/单品咖啡:Espresso(意大利咖啡)、ShortBlack、LongBlack(美式咖啡)、Decaf(无因咖啡)
2)调料:Milk、Soy(豆浆)、Chocolate
3) 要求在扩展新的咖啡种类时,具有良好的扩展性、改动方便、维护方便
4)使用OO的来计算不同种类咖啡的费用:客户可以点单品咖啡,也可以单品咖啡+调料组合。
方案一
方案设计如图:
问题分析
- Drink 是一个抽象类,表示饮料。
- des 就是对咖啡的描述,比如咖啡的名字。
- cost() 方法就是计算费用,Drink 类中做成一个抽象方法。
- Decaf 就是单品咖啡,继承Drink,并实现cost。
- Espress && Milk就是单品咖啡+调料,这个组合很多。
- 这样设计,会有很多类,当我们增加一个单品咖啡,或者一个新的调料类的数量就会倍增,就会出现类爆炸。
方案二
前面分析到方案1因为咖啡单品+调料组合会造成类的倍增,因此可以做改,将调料内置到Drink类,这样就不会造成类数量过多。从而提高项目的维护性(如图)
问题分析
- 方案2可以控制类的数量,不至于造成很多的类。
- 在增加或者删除调料种类时,代码的维护量很大。
- 在考虑到用户可以添加多份调料时,可以将hasMilk返回一个对应int。
- 考虑使用装饰者模式
方案三(装饰模式)
方案设计如图:
分析
这里主体跟实体大致不变,主要在抽象主体与调料中间添加了一个中间层。中间层的作用就是在调用cost的时候,他是要进行费用的叠加的,还有一个重要的就是中间层引入了一个Drink对象,这个对象其实包含着被装饰的对象,这个被装饰的对象,在调用coat的时候我们会获取他的费用,然后通过递归的放方式去获取这一级所有费用、同时具体装饰的名字可以通过getDescription()获取。就是外面包装那么多东西,也可以获取出来。
例如
装饰者模式下的举例订单:2份巧克力+一份牛奶的LongBlack
代码实现
抽象类
public abstract class Drink {
public String des;//描述
private float price = 0.0f;
public String getDes() {
return des;
}
public void setDes(String des) {
this.des = des;
}
public float getPrice() {
return price;
}
public void