设计模式 – Decorator
设计模式 – Decorator Decorator设计模式是典型的结构型模式 装饰模式:Decorator常被翻译成"装饰",我觉得翻译成"油漆工"更形象点,油漆工(decorator)是用来刷油漆的,那么被刷油漆的对象我们称decoratee.这两种实体在Decorator模式中是必须的. Decorator定义: 动态给一个对象添加一些额外的职责,就象在墙上刷油漆.使用Decorator模式相比用生成子类方式达到功能的扩充显得更为灵活. 下面是GOF的《Element of reusable Object-Oriented Software》中对Decorator用意的概述: Decorator Pattern――Attaches additional responsibilities to an object dynamically . Decorators provide a flexible alternative to subclassing for extending functionality . 1 何时需要使用装饰器模式 GOF的那本Bible中关于装饰器模式列举的是一个文本组件与边框的例子 下面举一个"三明治"的例子！ 很多人都吃过三明治，都会知道三明治必不可少的是两块面包片，然后可以在夹层里加上蔬菜、沙拉、咸肉等等，外面可以涂上奶油之类的。假如现在你要为一个三明治小店构造一个程序，其中要设计各种三明治的对象。可能你已经创建了一个简单的Sandwich对象，现在要产生带蔬菜的就是继承原有的Sandwich添加一个蔬菜的成员变量，看起来很"正点"的做法，以后我还要带咸肉的、带奶油的、带蔬菜的又分为带青菜的、带芹菜的、生菜的……还是一个一个继承是吧！假如我们还需要即带蔬菜又带其它肉类，设置我们还要求这些添加成分的任意组合，那你就慢慢继承吧！ 读过几年书的会下面这个算术，我们有n种成分，在做三明治的时候任意搭配，那么有多少种方案呢？！算算吧！你会有惊人的发现。N种成分，什么都不要是Cn0种方案吧！要1种是Cn1吧！…..要n种是Cnn吧！加起来不就是吗？Cn0+Cn1+……+Cnn-1+Cnn还不会啊！牛顿莱布尼兹公式记得吧！ (可惜Word的公式编辑器安装不了) 总共2的n次方案。有可能前面10天写了K个类，老板让你再加一种成分你就得再干10天，下一次再加一种你可得干20天哦！同时你可以发现你的类库急剧地膨胀！ (老板可能会说你: XXX前K天你加了n个成分，怎么现在这么不上进呢？后K天只加了1个成分啊？！！可能你会拿个比给老板算算，老板那么忙会睬你吗？！有可能你的老板会说: 不管怎么样我就要你加，K天你还给我加n个成分！！呵呵，怎么办啊！跳槽啊!跳槽了也没人要你！！人家一看就知道你没学设计模式) 。下面我们就使用装饰器模式来设计这个库吧！ 下面是各个类的意义: Ingredient (成分) : 所有类的父类，包括它们共有的方法，一般为抽象类且方法都有默认的实现，也可以为接口。它有Bread和Decorator两个子类。这种实际不存在的，系统需要的抽象类仅仅表示一个概念，图中用红色表示。 Bread (面包) : 就是我们三明治中必须的两片面包。它是系统中最基本的元素，也是被装饰的元素，和IO中的媒质流 (原始流) 一个意义。在装饰器模式中属于一类角色，所以其颜色为紫色。 Decorator (装饰器) : 所有其它成分的父类，这些成分可以是猪肉、羊肉、青菜、芹菜。这也是一个实际不存在的类，仅仅表示一个概念，即具有装饰功能的所有对象的父类。图中用蓝色表示。 Pork (猪肉) : 具体的一个成分，不过它作为装饰成分和面包搭配。 Mutton (羊肉) : 同上。 Celery (芹菜) : 同上。 ...