Head First 设计模式 第3章 装饰者模式

第3章 装饰者模式

1、定义/说明

　　动态、透明的将职责附加到对象上（或从对象上撤销），而不影响其他对象。若要扩展功能，装饰者模式提供了比继承更富有弹性的替代方案。

2、介绍

　　首先让我们先来介绍一下场景，EDI_KAI咖啡店开业了，需要有一套咖啡订单系统，以合乎他们的饮料供应需求。

　　注意：购买咖啡时，根据客户需要可以在其中加入各种调料，例如，蒸奶(Steamed Milk)，豆浆(Soy)，摩卡(Mocha也就是巧克力风味)或者覆盖奶泡

　　下面是我们的初步设计方案：

　　为了设计的健壮性，所以订单系统必须考虑到调料部分，我们的第一个尝试如下：

　　　　每个cost()方法将计算出咖啡加上订单上调料的价钱

　　发现设计上有什么问题了吗？这种近似“类爆炸”的设计，后期的维护简直就是噩梦。

　　如果我们使用装饰者模式来设计呢？会是什么样子呢？就让我们来看一下吧。

　　在这个需求中，总的来说，饮料（也就是咖啡）在确定之后是不会发生变更的，而调料就不一样了，不同的客户在选中同一种饮料之后可能会选择不同的调料，这时候我们就需要拿调料来为饮料调味（也就是我们说的用调料来装饰饮料），所以，我们以饮料为主题，然后在运行时以调料来装饰饮料,调料要继承或实现饮料主题。比方说顾客想要摩卡和奶泡深焙咖啡，我们要做的就是：

　　　　1）、拿一个深焙咖啡（DarkRoast）对象

　　　　2）、以摩卡（Mocha）对象装饰它

　　　　3）、以奶泡（Whip）对象装饰它

　　　　4）、调用cost()方法，并依赖委托(delegate)将调料的加钱加上去

　　

　　来看一下我们通过装饰者模式设计之后的类图：

　　解释下这个类图，其中Beverage(饮料)是一个抽象类或者接口（也就是我们说的主题/或者组件）；HouseBlend、DarkRoast、Espresso、Decaf作为具体的饮料（也就是被装饰者）继承自/实现Beverage超类；而CondimentDecorator作为装饰者基类也需要继承/实现Beverage超类，只有这样我们才能在运行时让装饰者去装饰被装饰者，以打到修改被装饰者的目的；Milk、Mocha、Soy、Whip作为具体的装饰者需要继承CondimentDecorator基类。

　　顺便说一下，JDK中的I/O就是采用的装饰者模式，如果以前的童鞋对这块不是很明白，在学习了装饰者模式后，估计很快就会明白了

　　本章要点：

　　Ж 定义：动态、透明的将职责附加到对象上（或从对象上撤销），而不影响其他对象。若要扩展功能，装饰者模式提供了比继承更富有弹性的替代方案

　　Ж 应用场景：

　　Ж 新设计原则：面向修改关闭，面向扩展开放

　　Ж 要慎用装饰者模式，除非必须，过度使用装饰者模式，小对象过多，会使程序变得非常负责。

关于第3章 装饰者模式模式就介绍到这里，如果以上内容有出错的地方，还请不吝赐教；如果大家觉得有讲的不明白地方，也可提出来，大家共同学习。

第4章的工厂模式会在最近几天更新....

谢谢阅读

转载请表明出处。