[设计模式]:面向复用的:Adapter,Decorator,Facade设计模式

忙忙碌碌终于是开始了复习，也终于能从头梳理下这门课介绍的所有设计模式了。

设计模式的分类

Adapter 适配器模式

字面意思：适配器模式，把某个类或者接口转换成我们期望的其他形式。

举个例子，比如我们要和一个外国人打交道，例如韩国人，如果我们没有学习过韩语，这个韩国人也没有学习过我们汉语，在这种情况下，我们之间是很难进行直接交流沟通。为了达到沟通的目的有两个方法：

1.改造这个韩国人，使其能够用汉语进行沟通；
2.请一个翻译，在我们和这个韩国人之间进行语言的协调。

显然第一种方式——改造这个韩国人的代价要高一些，我们不仅要重新培训他汉语的学习，还有时间、态度等等因素。而第二个方式——请一个翻译，就很好实现，而且成本低，还比较灵活，当我们想换个日本人，再换个翻译就可以了。

具体实现：
通过增加一个接口，将已经存在的子类封装起来，客户端只需要面向接口编程，从而隐藏了具体子类。

课件案例：

Decorator 装饰器模式

有的时候客户端需要一个有多种组合特性的object，比如stack，可能有UndoStack，SecureStack，SynchronizedStack等等实现了特殊操作的stack，但是如果我们需要特性的任意组合呢，如果还是单独的子类型的话，就会使继承结构变得十分复杂，带来大量的代码重复

解决方法：Decorator 装饰器模式：

对每一个特性构造子类，通过在子类中设计独特的功能，但是把基本的操作委托给底层的对象。

课本例子：
基本的stack和利用Decorator 实现的几种有特殊功能的栈


在此基础上，就能实现多种特性的组合：

Facade 外观模式

针对问题：有的时候有的系统功能很复杂，学习成本大。

解决方式：Facade 外观模式：
提供一个统一的接口来取代一系列小接口调用，相当于对复杂系统做了一个封装，简化客户端使用


facade门面角色：客户端和facade进行交互。此角色知道相关的(一个或者多个)子系统的功能和责任。当客户端想与众多的子系统进行交互时，facade角色会将所有从客户端发来的请求委派到相应的子系统去。

subsystem子系统角色：可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。

Facade模式的几个使用场景：
　　1、当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
　　2、客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
　　3、当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点，如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。