《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)饮料
例如：顾客想要摩卡和奶泡深焙咖啡

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

以装饰者构造饮料订单

• 以DarkRoast对象开始
  
  
  
  
  
  
  • DarkRoast继承自Beverage，且有一个用来计算饮料价钱的cost()方法
    
  
  
• 顾客想要摩卡(Mocha)，所以建立一个Mocha对象，并用它将DarkRoast对象包(wrap)起来
  
  
  
  
  
  
  • Mocha对象是一个装饰者，它的类型“反映”了它所装饰的对象（本例中就是Beverage）所谓“反映”指两者类型一致
    
  • 所以Mocha也有一个cost()方法。通过多态，也可以将Mocha所包裹的任何Beverage当成是Beverage（因为Mocha是Beverage的子类型）
    
  
  
• 顾客想要奶泡(Whip)，所以需要建立一个Whip装饰者，并用它将Mocha对象包起来。
  
  
  
  
  
  
  • Whip是一个装饰者，所以它也反映了DarkRoast类型，并包括一个cost方法
    
  • 所以被Mocha和Whip包起来的DarkRoast对象仍然是一个Beverage，任然可以具有DarkRoast的一切行为，包括调用它的cost()方法
    
  
  
• 算钱：通过调用最外圈装饰者(Whip)的cost()就可以办得到。Whip的cost()会先委托它装饰的对象(也就是Mocha)计算出价钱，然后再加上奶泡的价钱
  
  
  
  

小结

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

定义装饰者模式

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

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

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

注意：

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

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

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

系统实现

代码见开篇处仓库地址
Q：如果针对特定种类的具体组件，做特殊的时，这样的设计是否恰当。(例如，针对HouseBlend打折)
A：如果代码写成针对具体的组件类型，那么装饰者就会导致程序出问题，只有在针对抽象组件类型编程时，才不会因为装饰者而受到影响。如果的确需要针对特定的具体组件编程，就应该重新思考应用架构，以及装饰者模式是否合适。
Q：对于使用到饮料的某些客户来说，会不会容易不使用到最外面的装饰着呢？(即层层包装时产生了很多对象，有可能最终用错了，用的不是最外圈的)
A：使用装饰者模式的确必须管理更多对象，所以犯下这种编码错误的机会会增加。但是装饰者通常是用其他类似于工厂或生成器这样的模式创建的，它们会“封装的很好”，所以不会有这种问题。
Q：装饰者知道这一连串装饰链条中其他装饰者的存在吗？
A：装饰者该做的事就是增加行为到被包装对象上，当需要窥视装饰者链中的每一个装饰者事，这就超出他们的天赋了。但是可以通过其他方式实现需要借此完成的功能。
Java I/O中的装饰者

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

优点缺点解决具有为设计注入弹性的能力有时会在设计中加入大量的小类，会导致别人不容易了解其设计方式花点功夫对设计进行学习可以透明地插入装饰者，客户程序甚至不知道它是在和装饰者打交道人们在客户代码中依赖某种特殊类型，然后忽然导入到装饰者，却没有周详地考虑一切，就会出现问题在插入装饰者是，必须要小心谨慎/采用装饰者在实例化组件时，将增加代码地复杂度。一旦使用装饰者模式，不只需要实例化组件，还要把此组件包装进装饰者中采用工厂(Factory)模式和生成器(Builder)模式来解决此问题总结

OO基础

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

OO原则

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

OO模式

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

要点

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

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！