声明:仅为个人学习总结,还请批判性查看,如有不同观点,欢迎交流。
《Head First设计模式》第3章笔记:结合示例应用和代码,介绍装饰者模式,包括遇到的问题、遵循的 OO 原则、达到的效果。
示例应用是星巴兹(Starbuzz)咖啡店的订单系统。
最开始,店里只提供黑咖啡,系统类图如下:
Beverage
(饮料),是一个抽象类,咖啡店售卖的所有饮料都继承这个类
description
实例变量,用于保存饮料描述;getDescription()
方法,用于获取 description
;cost()
方法,用于获取饮料价格,由子类负责实现。Beverage
的子类:HouseBlend
(混合咖啡)、DarkRoast
(深度烘焙)、Decaf
(低咖啡因)、Espresso
(浓缩咖啡)
cost()
方法,计算具体饮料价格;description
,例如“最优深度烘焙”。后来,咖啡店提供了牛奶等调味配料,每份调料会收取一点费用。
随着调料和饮料的种类不断增加,现在系统急需进行更新。下面是当前的系统类图:
类爆炸!
调料的种类包括 Steamed Milk(蒸牛奶)、Soy(豆奶)、Mocha(摩卡,也被称为巧克力)、Whip(奶油泡沫)等,系统为每个“饮料和调料的组合”都创建了类。
我们来近距离观察一下 DarkRoastWithMochaAndWhip
(深焙摩卡奶泡咖啡)类的定义:
public class DarkRoastWithMochaAndWhip extends Beverage {
public DarkRoastWithMochaAndWhip() {
description = "Dark Roast with Mocha and Whip";
}
public double cost() {
return 0.99 + 0.2 + 0.1; // 基础饮料价格 + 各种调料价格
}
}
订购一杯“深焙摩卡奶泡咖啡”的方式如下:
Beverage beverage = new DarkRoastWithMochaAndWhip();
System.out.println(beverage.getDescription() + " $" + beverage.cost());
思考题:
很明显,星巴兹为自己制造了一个维护噩梦。请思考如下问题:【参考答案在第 20 行】
It’s pretty obvious that Starbuzz has created a maintenance nightmare for themselves. The Brain Power exercises:
1. 在牛奶价格上涨时,系统需要怎样调整? What happens when the price of milk goes up?
2. 当新增一种焦糖调料时,系统需要怎样调整? What do they do when they add a new caramel topping?
3. 系统设计明显违反了下面哪些设计原则?
分离变与不变、针对接口编程、优先使用组合、松耦合设计(下文 “5.2.2 原则回顾” 部分有详细些的原则介绍)
Which of the design principles that we’ve covered so far are they violating? (Hint: they’re violating two of them in a big way!)
书上没有提供答案,以下是我的理解,不知和你的是否一样。
1. 对于所有带牛奶调料的饮料类,都需要修改其 cost() 方法;(如果价格在每个类中硬编码)
2. 对于所有可搭配焦糖调料的饮料,都需要创建新的类;(类就是这样爆炸的)
3. 违反的原则
1)分离变与不变:变化的方面包括调料价格、调料类型、为基础饮料添加不同的调料
2)优先使用组合:系统完全采用继承方式进行设计
为了解决“类爆炸”,系统有了第1个版本的新设计,类图如下:
在 Beverage
类中:
milk
、soy
、mocha
、whip
实例变量,代表是否添加相应调料;has调料()
和 set调料()
方法,用于获取和设置调料的布尔值;cost()
不再是抽象方法:
cost()
中,计算当前饮料实例中所有调料的价格;cost()
中,通过超类 cost()
获得调料价格,再加上子类的基础饮料价格,就可以计算出总价格。超类 Beverage
的 cost()
方法实现如下:
public class Beverage {
public double cost() {
double condimentCost = 0.0; // 调料(condiment)总价格
if (hasMilk()) { condimentCost += 0.10; }
if (hasSoy()) { condimentCost += 0.15; }
if (hasMocha()) { condimentCost += 0.20; }
if (hasWhip()) { condimentCost += 0.10; }
return condimentCost;
}
}
子类 DarkRoast
的 cost()
方法实现如下:
public class DarkRoast extends Beverage {
public double cost() {
return 0.99 + super.cost(); // 基础饮料价格 + 所有调料价格
}
}
订购一杯“深焙摩卡奶泡咖啡”的方式如下:
Beverage beverage = new DarkRoast();
beverage.setMocha(true);
beverage.setWhip(true);
System.out.println(beverage.getDescription() + " $" + beverage.cost());
在第1版的新设计中,一共只有5个类,已经解决了“类爆炸”的问题。
思考题:
哪些需求或其它因素的改变会影响这个设计?(多选)【答案在第 20 行】
What requirements or other factors might change that will impact this design? (Choose all that apply.)
A. 任意一种调料的价格改变,都需要修改超类代码。Price changes for condiments will force us to alter existing code.
B. 每次增加新的调料时,都需要在超类中添加新的方法,并修改其 cost() 方法。
New condiments will force us to add new methods and alter the cost method in the superclass.
C. 未来可能会有某些饮料,并不适合某些调料,但是在这些饮料子类中,仍然要继承超类中的“那些不适合调料的”相关方法。
We may have new beverages. For some of these beverages (iced tea?), the condiments may not be appropriate, yet the Tea subclass will still inherit methods like hasWhip().
D. 如果顾客想添加双份摩卡,该怎么办?What if a customer wants a double mocha?
答案:A B C D
设计原则(Design Principle)
类应该对扩展开放,对修改关闭。
Classes should be open for extension, but closed for modification.
“开闭原则”的目标是允许类能够轻松地扩展,在不修改现有代码的情况下,就可以加入新的行为。
Our goal is to allow classes to be easily extended to incorporate new behavior without modifying existing code.
这样的设计具有弹性,可以应对改变;并且足够灵活,能够添加新的功能以满足不断变化的需求。
Designs that are resilient to change and flexible enough to take on new functionality to meet changing requirements.
结合“深焙摩卡奶泡咖啡”,我们来了解一种符合“开闭原则”的设计方式:
DarkRoast
和 DarkRoastWithMocha
两个类(暂时不考虑其它类)DarkRoastWithMocha
组合 DarkRoast
,即 HAS-A(有一个)DarkRoast
类型对象 wrappedObj
DarkRoastWithMocha
叫做 “装饰者”;DarkRoast
类型的实例变量 wrappedObj
叫做 “被装饰对象”;DarkRoastWithMocha
继承 DarkRoast
,即 IS-A(是一个)DarkRoast
类型
DarkRoast
)变量时:
这样,就可以在不改变 “被装饰对象” 的情况下,通过 “装饰者” 对 “被装饰对象” 进行扩展。即 “对修改关闭,对扩展开放”。
下面结合示例代码,了解具体的实现过程。
“被装饰对象”类的定义:
public class DarkRoast {
String description;
public DarkRoast() { description = "Dark Roast"; }
public String getDescription() { return description; }
public double cost() { return 0.99; }
}
“装饰者”类的定义:
public class DarkRoastWithMocha extends DarkRoast {
DarkRoast wrappedObj; // “被装饰对象”
// 创建“装饰者”时,需要指定“被装饰对象”
public DarkRoastWithMocha(DarkRoast darkRoast) { wrappedObj = darkRoast; }
// “装饰者”将行为委托给“被装饰对象”,并且在“被装饰对象”行为的基础上,“装饰”新的行为
public String getDescription() {
return wrappedObj.getDescription() + ", Mocha";
}
public double cost() {
return wrappedObj.cost() + 0.2;
}
}
订购一杯“深焙摩卡奶泡咖啡”的方式如下:
// 生成一份“深焙”
DarkRoast darkRoast = new DarkRoast();
System.out.println(darkRoast.getDescription() // "Dark Roast"
+ " $" + darkRoast.cost()); // 0.99
// 为“深焙”(被装饰对象)添加摩卡装饰,生成“深焙摩卡”(既是装饰者,又可以作为被装饰对象)
darkRoast = new DarkRoastWithMocha(darkRoast);
System.out.println(darkRoast.getDescription() // "Dark Roast, Mocha"
+ " $" + darkRoast.cost()); // 0.99 + 0.2 = 1.19
// 如果有奶泡装饰者 DarkRoastWithWhip 类,我们就可以
// 为“深焙摩卡”(被装饰对象)添加奶泡装饰,生成“深焙摩卡奶泡”(递归装饰)
// darkRoast = new DarkRoastWithWhip(darkRoast);
// System.out.println(darkRoast.getDescription() // "Dark Roast, Mocha, Whip"
// + " $" + darkRoast.cost()); // 1.19 + 0.1 = 1.29
// 目前还没有奶泡装饰者,但是我们可以
// 为“深焙摩卡”(被装饰对象)继续添加摩卡装饰,生成“深焙双摩卡”(重复装饰)
darkRoast = new DarkRoastWithMocha(darkRoast);
System.out.println(darkRoast.getDescription() // "Dark Roast, Mocha, Mocha"
+ " $" + darkRoast.cost()); // 1.19 + 0.2 = 1.39
上述示例在不改变 DarkRoast
对象的情况下,通过 DarkRoastWithMocha
,以动态(运行时)、透明(类型不变)的方式,扩展了对象的 getDescription()
和 cost()
行为。
在订单系统中,要采用上述类图结构,我们还需要进行一些完善。
首先,类图中不能只有摩卡,还要添加其它调料:
完善“装饰者”设计后的类图如下:
关于 “装饰者” 部分:
CondimentDecorator
DarkRoast
,并引用 DarkRoast
类型的 “被装饰对象” wrappedObj
;getDescription()
和 cost()
方法,由子类负责实现。Milk
、Mocha
、Soy
、Whip
CondimentDecorator
,实现 getDescription()
和 cost()
方法,接下来,类图中也不能只有深度烘焙,还要添加其它饮料:
和调料部分的设计一样,也将每种饮料封装在各自的类中,并定义统一的接口。
现在,我们获得了完整的、更新后的系统类图:
关于 “被装饰对象” 部分:
Beverage
getDescription()
方法,用于获取饮料描述 description
;cost()
方法,由子类负责实现,包括饮料子类和调料子类。HouseBlend
、DarkRoast
、Decaf
、Espresso
Beverage
,为 description
赋值,实现 cost()
方法。采用最新的设计之后,第1版设计 存在的问题 已经得到解决,系统 可以应对改变并易于扩展。
刚刚我们使用装饰者模式重新设计了咖啡店的订单系统,装饰者模式的正式定义如下:
装饰者模式(Decorator Pattern)
动态地给一个对象添加一些额外的职责。就增加功能来说,装饰者模式相比生成子类更为灵活。
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
增加功能的方式:生成子类 vs 装饰者模式
序号 | 生成子类 | 装饰者模式 | 装饰者模式【优缺点】 |
---|---|---|---|
1 | 给整个类添加功能 | 给某个对象添加功能 | 优点:让“被装饰对象”的类保持简单; 缺点:系统会产生许多看上去相似的“装饰者”类,不便于学习和调试; 缺点:在使用时,不仅要实例化“被装饰对象”,还要实例化各种需要的“装饰者” |
2 | 编译时静态添加功能 | 运行时动态添加功能 | 优点:可以在运行时动态添加功能、组合多种不同功能、重复添加一种功能 |
3 | 直接执行功能 | 委托“被装饰对象” 执行功能 |
优点:因为“装饰者”与“被装饰对象”具有相同的“超类型”,所以可以对用户透明; 缺点:不适用于依赖具体类型的代码,例如“被装饰对象”定义了某个方法 f() ,而“超类型”并没有定义 f() ,则不能通过“装饰者”执行 f() |
将订单系统中的类图抽象化,就可以得到设计模式中的类图:
Component
抽象类
operation()
。ConcreteComponent
“被装饰对象” 类
Component
,实现 operation()
方法;Decorator
“装饰者” 抽象类
Component
,即 IS-A(是一个)Component
,和 “被装饰对象” 具有相同的超类型;
Component
,即 HAS-A(有一个)Component
类型的 “被装饰对象” wrappedObj
;
operation()
方法,将行为委托给 “被装饰对象” wrappedObj
;ConcreteDecoratorA
“装饰者” 具体类
Decorator
,和 “被装饰对象” 具有相同的超类型;addedBehavior()
方法,实现向 “被装饰对象” 添加的新行为;operation()
方法,在委托 “被装饰对象” 执行 operation()
的基础上,附加 addedBehavior()
行为;
ConcreteDecoratorB
“装饰者” 具体类
Decorator
,和 “被装饰对象” 具有相同的超类型;newState
实例变量和 newBehavior()
方法
TextView
,“装饰者” 是滚动条 ScrollDecorator
,ScrollDecorator
中定义滚动状态 scrollPosition
和滚动行为 ScrollTo()
。operation()
方法,在委托 “被装饰对象” 执行 operation()
的基础上,根据需要附加额外行为。注:在设计模式中,重要的是模式的核心思想;在实际设计时,选择定义为接口还是抽象类,以及是否提供默认的方法实现等,可以根据具体的情境来决定。
延伸阅读:《设计模式:可复用面向对象软件的基础》 4.4 Decorator(装饰)— 对象结构型模式 [P132-139]
抽象饮料和调料类定义:
// Beverage.java
public abstract class Beverage {
String description = "Unknown Beverage";
public String getDescription() { return description;}
public abstract double cost();
}
// CondimentDecorator.java
public abstract class CondimentDecorator extends Beverage {
Beverage beverage;
public abstract String getDescription();
}
具体饮料类定义:
// DarkRoast.java
public class DarkRoast extends Beverage {
public DarkRoast() { description = "Dark Roast Coffee"; }
public double cost() { return .99; }
}
具体调料类定义:
// Mocha.java
public class Mocha extends CondimentDecorator {
public Mocha(Beverage beverage) {
this.beverage = beverage;
}
public String getDescription() {
return beverage.getDescription() + ", Mocha";
}
public double cost() {
return .20 + beverage.cost();
}
}
// Whip.java
public class Whip extends CondimentDecorator {
public Whip(Beverage beverage) {
this.beverage = beverage;
}
public String getDescription() {
return beverage.getDescription() + ", Whip";
}
public double cost() {
return .10 + beverage.cost();
}
}
测试代码:
// StarbuzzCoffee.java
public class StarbuzzCoffee {
public static void main(String args[]) {
Beverage beverage = new DarkRoast();
System.out.println(beverage.getDescription() + " $" + beverage.cost());
beverage = new Mocha(beverage);
System.out.println(beverage.getDescription() + " $" + beverage.cost());
beverage = new Mocha(beverage);
beverage = new Whip(beverage);
System.out.println(beverage.getDescription() + " $" + beverage.cost());
}
}
抽象饮料和调料类定义:
struct Beverage {
virtual ~Beverage() = default;
virtual std::string getDescription() const { return description; }
virtual double cost() = 0;
protected:
std::string description = "Unknown Beverage";
};
struct CondimentDecorator : public Beverage {
virtual ~CondimentDecorator() = default;
virtual std::string getDescription() const override { return beverage->getDescription(); }
virtual double cost() override { return beverage->cost(); }
protected:
CondimentDecorator(std::shared_ptr<Beverage> beverage) : beverage(beverage) {}
std::shared_ptr<Beverage> beverage;
};
具体饮料类定义:
struct DarkRoast : public Beverage {
DarkRoast() { description = "Dark Roast Coffee"; }
double cost() override { return .99; }
};
具体调料类定义:
struct Mocha : public CondimentDecorator {
Mocha(std::shared_ptr<Beverage> beverage) : CondimentDecorator(beverage) {}
std::string getDescription() const override {
return CondimentDecorator::getDescription() + ", Mocha";
}
double cost() override {
return CondimentDecorator::cost() + .20;
}
};
struct Whip : public CondimentDecorator {
Whip(std::shared_ptr<Beverage> beverage) : CondimentDecorator(beverage) {}
std::string getDescription() const override {
return CondimentDecorator::getDescription() + ", Whip";
}
double cost() override {
return CondimentDecorator::cost() + .10;
}
};
测试代码:
#include
#include
#include
// 在这里添加相关接口和类的定义
int main() {
std::shared_ptr<Beverage> beverage = std::make_shared<DarkRoast>();
std::cout << beverage->getDescription() << " $" << beverage->cost() << "\n";
beverage = std::make_shared<Mocha>(beverage);
std::cout << beverage->getDescription() << " $" << beverage->cost() << "\n";
beverage = std::make_shared<Mocha>(beverage);
beverage = std::make_shared<Whip>(beverage);
std::cout << beverage->getDescription() << " $" << beverage->cost() << "\n";
}
OO 基础回顾
5.2.1 新原则
类应该对扩展开放,对修改关闭。
Classes should be open for extension, but closed for modification.
5.2.2 原则回顾
5.3.1 新模式
装饰者模式(Decorator Pattern)
5.3.2 模式回顾
Hi, I’m the ENDing, nice to meet you here! Hope this article has been helpful.