JAVA学习之装饰者模式

装饰者设计模式

问题：为了给一个对象附加额外的功能，使用直接继承的方式，会带来大量的子类，

造成难以维护，使用装饰者设计模式，可以让这样的关系更加灵活，并利于扩展。

意图:

动态地给一个对象添加一些额外的职责。就增加功能来说，

Decorator模式相比生成子类更为灵活。

该模式以对客户端透明的方式扩展对象的功能。

适用环境：

在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。

处理那些可以撤消的职责。

当不能采用生成子类的方法进行扩充时。

一种情况是，可能有大量独立的扩展，

为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。

另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

装饰者设计模式的相关角色分配：

Component(被装饰对象基类)

定义对象的接口，可以给这些对象动态增加职责;

ConcreteComponent(具体被装饰对象)

定义具体的对象，Decorator可以给它增加额外的职责;

Decorator(装饰者抽象类)

维护指向Component实例的引用，定义与Component一致的接口;

ConcreteDecorator(具体装饰者)

具体的装饰对象，给内部持有的具体被装饰对象增加具体的

装饰者模式小结:

OO原则：动态地将责任附加到对象上。

想要扩展功能，装饰者提供有别于继承的另一种选择。

要点:

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

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

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

4、除了继承，装饰者模式也可以让我们扩展行为。

5、装饰者模式意味着一群装饰者类，这些类用来包装具体组件。

6、装饰者类反映出被装饰的组件类型(实际上，他们具有相同的类型，

     都经过接口或继承实现)。

7、装饰者可以在被装饰者的行为前面与/或后面加上自己的行为，

     甚至将被装饰者的行为整个取代掉，而达到特定的目的。

8、你可以有无数个装饰者包装一个组件。

9、装饰者一般对组建的客户是透明的，除非客户程序依赖于组件的具体类型。