《Head First设计模式》读书笔记 —— 装饰者模式

《Head First设计模式》读书笔记
相关代码：Vks-Feng/HeadFirstDesignPatternNotes: Head First设计模式读书笔记及相关代码

给爱用继承的人一个全新的设计眼界

本节用例

Starbuzz咖啡因迅速扩展，准备更新订单系统，以合乎其饮料供应需求

原有类设计如下：

在购买咖啡时，可以在其中加入各种调料，系统需要考虑调料部分计算费用

第一版尝试——枚举所有情况

第一版尝试(枚举所有情况)：简直是“类爆炸”

这是一个“维护恶梦”

• 当有饮料或者调料价格变动，或有新调料出现……

第二版尝试——实例变量&继承

从基类Beverage下手，添加实例变量代表是否加上调料

再加入子类，每个类表示菜单的一种饮料

哪些需求或因素改变时会影响这个设计？

• 调料价钱的改变会使我们更改现有代码
• 一旦出现新的调料，我们就需要加上新的方法，并改变超类中的cost()方法
• 当出现新饮料时，明显不相配的调料也会被继承
• 当顾客想要双倍摩卡咖啡时，如何处理……

回顾：组合和委托

尽管继承威力强大，但是它并不总是能实现最有弹性和最好维护的设计。而通过利用组合(composition)和委托(delegation)可以在运行时具有继承行为的效果

• 利用继承设计子类的行为：
  • 在编译时静态决定
  • 所有子类都会继承到相同的行为
• 利用组合扩展对象的行为：
  • 动态地进行扩展
  • 可将在设计超类时还没有想到的职责加到对象上，且不用修改原有代码

利用组合维护代码：通过动态地组合对象，可以写新的代码添加新功能，而无需修改现有代码，引进bug或者产生意外副作用的机会将大幅度减少

开放-关闭原则

代码应该如同晚霞中的莲花一样地关闭(免于改变)，如同晨曦中的莲花一样地开放(能够扩展)

HeadFirst设计原则4 ：类应该对扩展开放，对修改关闭

开放：通过用任何想要的行为扩展类，应对需求的改变
关闭：已经花了很多时间确保代码的正确，修改现有代码可能会导致许多问题

目标：允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。这样的设计具有弹性，可以应对改变，接受新的功能来应对改变的需求

Q：“对扩展开放，对修改关闭”听上去很矛盾，设计如何兼顾两者？
A：有一些聪明的OO技巧，允许系统在不修改代码的情况下，进行功能扩展。例如观察者模式中，通过加入新的观察者，我们可以在任何时候扩展主题，且不需要向主题中添加代码。

Q：如何将某件东西设计成可以扩展，又禁止修改？
A：学习装饰者模式

Q：如何让设计的每个部分都遵循“开放-关闭”原则
A：通常很难办到，这需要花费很多时间和努力。遵循开放-关闭原则，通常会引入新的抽象层次，增加代码的复杂度。我们需要把注意力集中在设计中最有可能改变的地方，然后在那里应用开放-关闭原则

认识装饰者模式

为了解决Starbuzz的问题，我们采用与上述不一样的做法：以饮料为主体，然后在运行时以调料来“装饰”(decorate)饮料

例如：顾客想要摩卡和奶泡深焙咖啡

1. 拿一个深焙咖啡(DarkRoast)对象
2. 以摩卡(Mocha)对象装饰它
3. 以奶泡(Whip)对象装饰它
4. 调用cost()方法，并依赖委托(delegate)将调料的价钱加上去

以装饰者构造饮料订单

1. 以DarkRoast对象开始
   

   • DarkRoast继承自Beverage，且有一个用来计算饮料价钱的cost()方法

2. 顾客想要摩卡(Mocha)，所以建立一个Mocha对象，并用它将DarkRoast对象包(wrap)起来
   

   • Mocha对象是一个装饰者，它的类型“反映”了它所装饰的对象（本例中就是Beverage）所谓“反映”指两者类型一致
   • 所以Mocha也有一个cost()方法。通过多态，也可以将Mocha所包裹的任何Beverage当成是Beverage（因为Mocha是Beverage的子类型）

3. 顾客想要奶泡(Whip)，所以需要建立一个Whip装饰者，并用它将Mocha对象包起来。
   

   • Whip是一个装饰者，所以它也反映了DarkRoast类型，并包括一个cost方法
   • 所以被Mocha和Whip包起来的DarkRoast对象仍然是一个Beverage，任然可以具有DarkRoast的一切行为，包括调用它的cost()方法

4. 算钱：通过调用最外圈装饰者(Whip)的cost()就可以办得到。Whip的cost()会先委托它装饰的对象(也就是Mocha)计算出价钱，然后再加上奶泡的价钱
   

小结

• 装饰者和被装饰对象有相同的超类型
• 你可以用一个或多个装饰者包装一个对象
• 既然装饰者和被装饰对象有相同的超类型，所以在任何需要原始对象（被包装的）的场合，可以用装饰过的对象代替它
• ==装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的
• 对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地使用你喜欢的装饰者来装饰对象

定义装饰者模式

HeadFirst设计模式3-装饰者模式

装饰者模式动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案

把装饰者模式用于Starbuzz系统，得到类图如下：

注意：

• “继承的目的”：此处CondimentDecorator扩展自Beverage类时用到了继承，但是这里“继承的重点”是达到“类型匹配”的目的（因为装饰者和被装饰者必须是一样的类型），而非利用继承获得“行为”
• 新行为的来源：将装饰者与组件组合时，就是在加入新的行为。即行为通过组合对象得来

一言以蔽之：继承超类是为了有正确的类型，而不是继承他的行为。行为来自装饰者和基础组件，或与其他装饰者之间的组合关系。

好处：

• 使用对象组合，可以把饮料和调料更有弹性地加以混合与匹配，十分方便
• 组合而非继承，实现“运行时”而非“编译时”
• 无需修改现有代码

系统实现

代码见开篇处仓库地址

Q：如果针对特定种类的具体组件，做特殊的时，这样的设计是否恰当。(例如，针对HouseBlend打折)
A：如果代码写成针对具体的组件类型，那么装饰者就会导致程序出问题，只有在针对抽象组件类型编程时，才不会因为装饰者而受到影响。如果的确需要针对特定的具体组件编程，就应该重新思考应用架构，以及装饰者模式是否合适。

Q：对于使用到饮料的某些客户来说，会不会容易不使用到最外面的装饰着呢？(即层层包装时产生了很多对象，有可能最终用错了，用的不是最外圈的)
A：使用装饰者模式的确必须管理更多对象，所以犯下这种编码错误的机会会增加。但是装饰者通常是用其他类似于工厂或生成器这样的模式创建的，它们会“封装的很好”，所以不会有这种问题。

Q：装饰者知道这一连串装饰链条中其他装饰者的存在吗？
A：装饰者该做的事就是增加行为到被包装对象上，当需要窥视装饰者链中的每一个装饰者事，这就超出他们的天赋了。但是可以通过其他方式实现需要借此完成的功能。

Java I/O中的装饰者

Java I/O引出了装饰者模式的一个“缺点”：利用装饰者模式，常造成设计中有大量的小类，数量众多，可能会造成使用此API程序员的困扰

装饰者模式优缺点

总结

OO基础

• 抽象
• 封装
• 多态
• 继承

OO原则

• 封装变化
• 多用组合，少用继承
• 针对接口编程，不针对实现编程
• 为交互对象之间的松耦合设计而努力
• 对扩展开放，对修改关闭

OO模式

• 装饰者模式——动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案

要点

• 继承属于扩展形式之一，但不见得是达到弹性设计的最佳方式
• 我们的设计中，应该允许行为可以被扩展，而无需修改现有的代码
• 组合和委托可用于在运行时动态地加上新的行为
• 除了继承，装饰者模式也可以让我们扩展行为
• 装饰者模式意味着一群装饰者类，这些类用来包装具体组件
• 装饰者类反映出被装饰的组件类型（事实上，他们具有相同的类型，都经过接口或继承实现）
• 装饰者可以在被装饰者的行为前面与/或后面加上自己的行为，甚至被装饰者的行为整个取代掉，而达到特定的目的
• 你可以用无数个装饰者包装一个组件
• 装饰者一般对组建的客户是透明的，除非客户程序依赖于组件的具体类型
• 装饰者会导致设计中出现许多小对象，如果过度使用，会让程序变得很复杂