装饰者模式—GOF的23个之一

装饰者模式—GOF的23个之一

 

前言：同样来自《Head First 设计模式》,不涉及任何商务往来，仅为学习使用，作为参照笔记。『『装饰者模式』——动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

汗，发布了一天，才发现题目写错了。意外……

 

装饰者模式类图

 

 

 

 

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

 

补充：

关联：A拥有B，B是A的变量。

依赖：A使用B，B在A的方法中。

 

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

 

开放-关闭原则

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

 

一、我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。如能实现这样的目标，有什么好处呢？这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。

回顾观察者模式（在第2章）……通过加入新的观察者，我们可以在任何时候扩展Subject（主题），而且不需向主题中添加代码。

 

二、装饰者模式—完全遵循开发-关闭原则。

 

三、不能处处遵循开放-关闭原则。遵循开放-关闭原则，通常会引入新的抽象层次，增加代码的复杂度。你需要把注意力集中在设计中最有可能改变的地方，然后应用开放-关闭原则。

 

四、“装饰（decorate）饮料”（装饰者模式可以用以下思路。）

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

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

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

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

 

如何装饰一个对象？（暗示：把装饰者对象当成“包装者”。）

“委托”如何与此搭配使用？

 

五、重要知识点归纳：

1、装饰者和被装饰对象有相同的超类型。

2、你可以用一个或多个装饰者包装一个对象。

3、既然装饰者和被装饰对象有相同的超类型，所以在任何需要原始对象（被包装的）的场合，可以用装饰过的对象代替它。

4、装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的。（不太好理解。）

5、对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。

 

附一些小解释：

component 组件    condiment调料

concrete 具体

decorator 装饰者

 

六、重点点出

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

当我们将装饰者与组件组合时，就是在加入新的行为。所得到的新行为，并不是继承自超

类，而是由组合对象得来的。（重点）

继承Beverage抽象类（超类），是为了有正确的类型，而不是继承它的行为。行为来自装饰者和基础组件，或与其他装饰者之间的组合关系。

 

七、继承与组合

利用继承，类的行为只能在编译时静态决定。

利用组合，类的行为可以在任何时候变化。

 

八、Beverage类常用抽象类，而不是接口。（原理，不知道，一种习惯吧！！）

 

装饰者模式在IO中运用

 

 

九、小知识点归纳：（部分优、缺点）

优点：装饰者模式有能力为设计注入弹性。

缺点：

（1）在设计中加入大量的小类。

（2）类型问题。装饰者模式依赖某些特殊典型，在插入装饰者时，必须要小心。

（3）采用装饰者在实例化组件时，将增加代码的复杂度。

（最后一个问题，工厂Factory和生成器Builder模式会帮其改善。）

 

十、回顾要点

1、继承属于扩展形式之一，但不见得是达到弹性设计的最佳方式。

2、在我们的设计中，应该允许行为可以被扩展，而无须修改现有的代码。

3、组合和委托可用于在运行时动态地加上新的行为。

 

 

如有好的建议，可留言或发至笔者邮箱：fzb_xxzy@163.com