装饰者模式

我们的目标是实现更大的弹性和更好的可维护性的设计。

运行时扩展，远比编译时期的继承威力大。

对于继承存在的继承滥用问题，装饰者模式给爱用继承的人了一个全新的设计眼界。

一旦你熟悉了装饰的技巧，你将能够在不修改任何底层代码的情况下，给你的（或别人的）对象赋予新的职责。

1）首先，我们要设计的是星巴兹咖啡店的各饮品名目

---

 

起初的类设计：

 

当人们购买咖啡时，可以要求加入各种调料，而我们需要根据调料的不同，对售卖的咖啡进行计价。

所以我们可以这样进行处理：

 

无疑，这种滥用继承的设计结果使我们所不能接受的。

当其中一种调料的价格变动或者再加入一种新的调料时，我们会发现我们进行维护的成本是巨大的。

2）现在我们考虑第二种设计实现。对于上述步骤中的继承类爆炸的状态，我们可以不设计这么多类，而是利用实例变量和继承，就可以追踪这些调料。

---

 

 

这样我们所实现的类就比1）中少了很多。似乎这是一个可行的解决办法，但是，又似乎隐隐存在着些问题！

我们知道，虽然继承的威力强大，但是它不总是能够实现最有弹性和最好维护的设计。

为了不通过“继承”而实现代码复用，我们可以利用组合（composition）和委托（delegation），使得我们的程序可以在运行时具有继承行为的效果。

利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展到对象的行为，就可以在运行时动态地进行扩展。

我们可以利用这个技巧把多个新职责，甚至是设计超类时还没有想到的职责加载对象上，而且重要的是，我们不用修改原来的代码。因为我们没有改变现有代码，那么引进bug或产证意外副作用的机会将大幅度减少。

此时，我们介绍一下新的设计原则：

我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。

这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。

但是在选择需要被扩展的代码部分时要小心。每个地方都采用开放—关闭原则，是一种浪费，也没有必要，还会导致代码变得复杂且难以理解。

3）让我们来看一看装饰者模式的大概概念

---

 

归纳一下：

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

4）定义装饰者模式

---

 

有没有发现什么吊诡的地方，不是说好的不用“继承”么？还以为会用“组合”代替“继承”，没想到还是得用“继承”。

在装饰者模式中，的确是如此，但是这么做的重点在于装饰者和被装饰者必须是一样的类型，也就是有共同的超类，这是相当关键的地方。在这里，我们利用继承达到“类型匹配”，而不是利用继承获得“行为”。

那么“行为”从哪里来？我们在将装饰者与组件组合时，就是在加入新的行为。所得到的新行为，并不是继承自超类，而是由组合对象得来的。

所以，“行为”来自装饰者和基础组件，或与其他装饰者之间的组合关系。而且因为使用对象组合，可以把所有饮料和调料更有弹性地加以混合与匹配。

那么在这个例子中为什么不把Beverage类设计成一个接口，而是设计成一个抽象类呢？

因为在本例子的题目中，Beverage就已经是一个“抽象类”了，通常装饰者模式是采用抽象类，但是在Java中可以使用接口。尽管如此，通常我们都努力避免修改现有的代码，所以，如果抽象类运作得好好的，还是别去修改它了，我们不妨“懒”一下。

5）具体实现本例中的代码

---

 

6）真实世界的装饰者：Java I/O

 

---

 

7）小结

---

 

装饰者模式可以为设计注入弹性，但是也会在设计中加入大量的小类。这个可以配合工厂模式（Factory）和生成器（Builder）模式使用，对装饰者模式进行优化改进。

OO基础：

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

 

OO原则：

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

 

OO模式：

• 策略模式——定义算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户
• 观察者模式——在对象之间定义一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并自动更新
• 装饰者模式——动态地将责任附加到对象上。想要扩展功能，装饰者提供有别于继承的一种选择

 

要点：

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

 

参考书目：《Head First 设计模式》