【大话设计模式】——结构型模式总结

    结构型设计模式主要是从结构上解决代码的耦合问题。包含一下7种模式：Adapter，Proxy,Composite,Bridge,flyweight,Facade，Decorator。结构型中包含7个模式，有点多，不过比行为型模式少，但也容易忘记，加点魔术粉让我们忘不了。

   首先，我们要先知道这7个模式都是什么意思。

一、概念

    1、Adapter:将一个类的接口转换为客户希望的另一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作的那些类一起工作。

 

    个人理解：看到这个模式让我想起了编码，我有我的编码规则，你有你的编码规则，你说的话我听不懂，咱们两个就无法交流。如果中间有一个朋友，将你说的话解释给我听，我们就可以正常交流。（这个朋友就充当了适配器的角色）。怎么感觉这么像解释器啊！

    2、Proxy：为其他对象提供一种代理以控制对这个对象的访问。

    个人理解：这让我想起来小学某男生写了情书，找人代替他送给某女生。自己不去做，找人代替他去做。生活中最常见的例子就是某化妆品代理，厂商招了代理，帮助他来卖化妆品，代理直接与客户打交道，而厂商不直接与客户打交道。

    3、Composite：将对象组合成树形结构以表示“部分——整体”的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。

    个人理解：就像我们提高班的组织结构一样。首先，提高班这是一棵树，九期，十期，十一期，十二期是树枝，树枝上有树叶：CEO，各委员会。而提高班这棵树上也有树叶：CEO，各委员会。高层的CEO，各委员会与低层的CEO，委员会等职责是一样的。

    4、Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化。

    个人理解：如果一个东西可以有两种实现方式，那么可以将这两种实现方式独立起来。

    5、flyweight：运用共享技术有效的支持大量细粒度的对象。

    个人理解：共享，前几天师哥师姐们说的高校云平台不就是这么一个道理吗？共用一套数据库，利用ID来区分不同学校，以及不同数据和模板。

    6、Facade：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

     

    个人理解：重新定义了一个接口，此接口与客户，与各子系统连接，而子系统的改变，不会影响到客户，或者说客户不需要知道具体的子系统是什么！

    7、Decorator：动态的给一个对象添加额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。

   个人理解：如果客户对此产品不满意，需要增加一个需求，这时候就不用添加创建新的派生类，可以用装饰模式给一个类添加职责。

  其次，找关系！

 二、比较

1、Adapter VS Proxy

相同点：两种模式都是两者不可以直接访问，需要一个第三者来完成两者之间的访问。

不同点：Adapter是来弥补对象在新环境下的不足之处。

        Proxy是来解决两个对象不可以直接访问的问题。

2、Decorator VS Bridge 

相同点：两者可以独立变化，减少派生类的增长。

不同点：Bridge适合多个维度变化的一种模式。

        Decorator是适合新需求的不断增加的一种模式。

    最后，总结一下收获！

三、总结

    三种类型的设计模式都学完了，才发现自己的草稿箱还有一篇未发表的博客，实在是罪过啊，以后可不该这样做了，要写博客就要在晚上九点之前更新完，要不然就会拖拉，拖着拖着就忘记了。。。。。。