前言
设计模式系列代码均持续更新在我的gitHub：to github
装饰者模式定义
- 在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）
装饰者模式成员
- 抽象构件（Component）角色：定义一个抽象类或接口以规范准备接收附加责任的对象。
- 具体构件（ConcreteComponent）角色：实现抽象构件，通过装饰角色为其添加一些职责。
- 抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。
- 具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。
类图
核心代码
- 抽象构建，省略get/set
public abstract class Drink {
private String desc; // 描述
private float price;
// 计算费用的抽象方法
// 交给子类去实现
public abstract float cost();
}
- 具体构件的缓冲层，为其下子类实现 cost()
public class Coffee extends Drink {
public float cost() {
return super.getPrice();
}
}
- 具体构件之一
public class Decaf extends Coffee {
public Decaf() {
setDesc(" Decaf Coffee ");
setPrice(10.00f);
}
}
- 抽象装饰（装饰者模式的核心类!）
public class Decorator extends Drink {
private Drink drink;
public Decorator(Drink drink) {
this.drink = drink;
}
/* 递归求总价格
* getPrice = setPrice() 的值，相当于调料的价格
* this.drink.cost() 相当于单品咖啡 + 之前就已经加入的调料的价格 */
public float cost() {
return getPrice() + this.drink.cost();
}
@Override
public String getDesc() {
return this.drink.getDesc() + "加了" + super.getDesc();
}
}
- 具体装饰之一
public class Milk extends Decorator {
public Milk(Drink drink) {
super(drink);
setDesc(" 牛奶 ");
setPrice(3.0f); // 调味品的价格
}
public void addSweet() {
System.out.println("牛奶给咖啡加了点甜味");
}
}
总结
装饰者模式的优点
- 完全符合ocp原则
- 扩展类的功能很方便
装饰者模式的缺点
- 我觉得缺点就一个： 类间关系难理解
装饰者模式应用场景[个人理解]
- 当有一个类或一个族（向上继承同一个父类）需要添加新的功能时，可以写一个装饰器类，继承并聚合该父类，然后写具体的装饰类，继承装饰器类，并添加新的方法。
