Decorator 模式中遭遇继承与聚合的冲突
2005-03-07 08:17 作者:M_D_R 出处:blog 责任编辑:方舟
一:背景:Decorator
*Decorator 常被翻译成"装饰",我觉得翻译成"油漆工"更形象点,油漆工(decorator)是用来刷油漆的,那么被刷油
漆的对象我们称 decoratee.这两种实体在 Decorator 模式中是必须的。
*Decorator 定义:
动态给一个对象添加一些额外的职责,就象在墙上刷油漆.使用 Decorator 模式相比用生成子类方式达到功能的扩充
显得更为灵活。
*为什么使用 Decorator?
我们通常可以使用继承来实现功能的拓展,如果这些需要拓展的功能的种类很繁多,那么势必生成很多子类,增加
系统的复杂性,同时,使用继承实现功能拓展,我们必须可预见这些拓展功能,这些功能是编译时就确定了,是静态的。
使用 Decorator 的理由是:这些功能需要由用户动态决定加入的方式和时机.Decorator 提供了"即插即用"的方法,在
运行期间决定何时增加何种功能。
*对于该模式,初步归纳为
1.基本功能为接口
2.Decorator 参数为接口本身也为接口以便为下一个 Decorator 的参数
3.基本功能类实现接口 并作为 Decorator 构造函数的参数,以便在此基础上添加新功能
4.额外功能由 Decorator 中的数据结构处理
二:问题
这是一段 Decorator 设计模式的实现例子如下:
基本功能:Counter 类
需要添加的功能
1:上限控制
2:下限控制
import java.io.*;
class Counter{