Decorator 模式

名称：装饰模式，包装模式（wapper）

问题：

需要扩展一个类的功能，或者给以各类增加附加职责；需要动态给一个对象增加功能，这些功能可能动态撤销；需要增加基本功能的排列组合产生非常大量的功能，从而使得继承关系变得不现实。

例如：

一个图形界面工具箱允许你对一些用户界面元素增加一些特性（例如边框之类），使用继承是可以的，但是，假设由很多特性需要增加，显然我们无法增加那么多特性。

解决：

将组件嵌入到另外一个对象中，由这个对象添加边框等特征，且称这个嵌入的对象为装饰，这个装饰同他所装饰的组件接口一致，因此对于使用其的用户来说是透明的。该装饰对象将接口方法请求转给组件，且有机会在转发前后进行相关“装饰”操作，且可以允许你递归嵌套装饰以实现更多的特征。

效果：

可动态、任意扩充组件信特征，且可以任意递归调用增加。可以处理“撤销”职责行为。客户不会感觉到装饰同组件的区别，也不会对装饰产生任何依赖。

图：

Facede 模式

名称：门面模式、外观模式

问题：

    假设一个编程环境，含有多个子类，譬如scanner、programnode…...等用于实现编译环境。但是，对于用户大多数任务来讲，用户并不关心编译中得实现细节，编译环境中的子类只会使得用户觉得复杂。

解决：

    增加一个Complier类，定义并实现一个编译器统一的必须的接口，可以不掩藏实现细节的类而组合一个可供用户使用的系统接口。这个Complirer类实际就是编译子系统的门面（注意，并未要求这些子类完全隐藏）。

效果：

    可以对客户屏蔽子系统，减少了客户的负担。实现了子系统同客户件的松散耦合。但是，如果系统需要，并不限制子系统的请求。

图：