常用设计模式二

      ——————————————结构型模式————————————

    1、 Facade模式

      Facade模式的意图是为子系统的一组接口提供一个统一的界面（Facade）， 定义了一个高层次的接口， 使得使用这个子系统更为容易。

    Facade模式实际上简化和理顺了客户端与系统的依赖关系， 减低了它们之间的耦合度。这是一种应用很广泛的模式， 特别是网络通信和远程调用方面， 它的优势尤为明显。 在EJB的应用中， Session Facade模式最为经典。

 

  2、 Proxy模式

      代理模式的意图是： 为其他对象提供一个代理以控制对这个对象的访问， 具体来说， Proxy模式适合以下情况：

  a、 某个客户端不能直接访问某个对象， 但是必须要和这个对象交互。

 b、 授权机制， 不同的客户对同一对象有不同的访问权限。

 c、 创建或加载的对象很大， 很消耗时间， 阻碍了业务的流程。

     Proxy模式应用比较广泛， 在常见多为WEB服务器中， 如果客户浏览器对同一面访问率很大的话， 带来的结果将是这个页面的很多复本通过服务器传输到浏览器， 这样很容易造成WEB服务器压力过大， 响应迟钝。 如何解决这个问题呢？ 我们可以在服务器端做一个缓存代理， 这个缓存代理能缓存最近被访问过的页面， 并且， 当一个客户请求到达时， 它能够判断这个请求的页面是否已经在缓存中， 如果是则直接返回内存复制给浏览器； 如果不是才把请求交给WEB服务器处理

 

  3、 Bridge模式

   Bridge模式的意图是： 将抽象部分与实现部分分离， 使得它们可以独立的变化。  ^_^  ^_^  这其实就是之前那个“开闭原则”的一个体现， 它主要适应以下情形：

  a、 不希望在抽象和它的实现部分之间存在固定的绑定关系， 以便在程序运行时刻实现部分可以动态地被选择或者切换。

  b、 需要对客户完全隐藏抽象的实现部分

 c、 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充， 对一个抽象的实现部分的修改应该对客户不产生任何影响， 客户的代码不必重新编译。

 

4、 Adapter模式

     Adapter模式： 将一个类的接口转换成客户希望的另外一个接口， 使得原本由于接口不兼容而不能在一起工作的那些类一起工作。 它适应以下情况：

  a、 需要使用一个已经存在的类， 但它的接口不符合需求

  b、 想创建一个可以复用的类， 该类可以与其他不相关的类或不可以遇见的类系统工作

  c、 想使用一些已经存在的子类， 但是不可能对每一个都进行子类化以匹配它们的接口， 对象适配器可以适配它的父类接口。

    要实现 Adapter模式一般有两种方式： 组合和继承。关于取舍得遵循OO设计原则中的合成/聚合原则。