结构型设计模式总结

    结构型设计模式涉及到如何组合类和对象以获得更大的结构。首先我问了自己一个问题：我为什么要获得更大的结构，不要这种大的结构不行吗？细想之下我发现其实这种大的结构不是我想不想要的问题，而是客观世界对我设计的软件需要这种或那种较大的不同类型的结构。那么客观世界中都有哪几种主要的结构要求呢，这些结构要求的实现可能有什么问题，我们怎么来解决呢？这些问题都将交给前人（愿意将经验分享给大家的人）的经验——设计模式——来解答。

     一、由含义看这七种结构型设计模式：

其实从每种设计模式的含义就可以品味出这种设计模式要解决的问题。

   （一）先看下这七种结构型设计模式的定义。

     1、桥接模式（bridge）：将抽象部分与实现部分分离，使它们可以独立的变换（实现系统可能有多角度的分类，每种分类都有可能变化，那么我们就将他们分离出来，让他们独立变化，减少它们之间的耦合）

     2、装饰模式（Decorator）：动态的给一个对象增加一些额外的职责。

     3、组合模式（composite）：将对象组合成树型结构以表示“部分-整体”的关系，使得用户对单个对象和组合对象的使用具有一致性。

     4、代理模式（proxy）：为其他对象提供一种代理以控制对这个对象的访问。

     5、适配器模式（adapter）：将一个类的接口转换成客户所需要的另外一个接口。Adapter使得原本由于接口不兼容不能一起工作的类可以一起工作了。

     6、享元模式（flyweight）：运用共享技术有效地支持大量细粒度的对象。

     7、外观模式（facade)：为子系统中的一组接口提供了一个一致的界面（一个高层接口），这使得这一子系统更加容易使用。

    （二）疑点解析

     1、在bridge Pattern中将抽象部分与实现部分分离中的抽象部分和我们在面向对象编程中的继承中的抽象有所不同。首先在Bridge Pattern中抽象有一个确确实实的抽象，还有一个或多个被提炼的抽象（refinedAbstraction）。再有就是继承中我们要的是这种抽象不在变化，而只是在继承中对其进行功能的扩展，继承机制将它的抽象部分与实现部分固定在一起，那一对抽象部分和实现部分分别进行修改、扩充和重用；而Bridge Pattern确实抽象部分与实现部分都要变化的问题。

     2、组合模式（Composite Pattern）说的对单个对象和组合对象使用上具有一致性。对于这一点我们要先理解对于树形结构中的复杂元素（如树枝，它可能还包含其他树枝，和叶子）和简单元素（如树叶，它不可能在包含其他元素），这两个概念搞清楚后，我们要清楚其实Composite Pattern就是使客户模糊了简单元素和复杂元素。客户程序可以像处理简单元素一样来处理复杂元素。现在再看下facade Pattern（外观模式）它好像也对其客户模糊了复杂的子系统，但不同点在于Composite Pattern有一个树型结构，这就不只是一个子系统那么简单了，而是可以构成一个庞大的体系（如一个跨国公司的各个分公司和部门）

    二、由类图看这七种结构型设计模式：

可以说每种设计模式的类图描述的正是这种设计模式是怎样解决系统结构扩大过程中出现的问题的。而我们在设计模式中所看到的每种设计模式的类图都可以看成是解决这种问题的一种实现方案，也就是说其实每种设计模式可以有不同形式的类图（如我们可以对Decorator Pattern或其他模式进行缩小或 扩充等修改，重要的是找到合适的实现方式）。每种结构型设计模式的类图查看前面定义中的链接。

   三、由模式名称看设计模式

    1、Decorator Pattern要看的就是装饰类了，这个类里has a 其抽象类，这样便可对其他继承此抽象类的类进行装饰了。当然装饰谁也得通过实理化的过程中在sub new或其他自定义函数中指定。

    2、Composite Pattern(组合模式)：看Composite Pattern的类图和其代码实现我们会发现，这种模式与其他模式的不同之处除了有一个必须的ADD（）过程和一个Remove（）过程之外，最核心的就是Composite子类的实现，而且这也是客户端要使用的类。

   3、Bridge Pattern 就是通过在抽象部分中has 实现部分来完成实现与抽象两部分的桥接的，使它们能够独立的变化。

   4、proxy Pattern中会定义一个接口使代理对象（proxy）能为被代理对对象（RealSubject）做所有事情。而这一方面是靠一个subject的抽象类或接口，另一方面则是靠Proxy类中has a RealSubject对象（被代理对象）。

   5、Adapter Pattern中，主要看Adapter如何达到适配的作用，前提就是要使Adapter类有和目标接口类（Target）有相同的接口，他们为继承关系。再有就是Adapter类中还需要has a 被适配的对象（adaptee）以便真正达到适配作用。

   6、flyweight Pattern中享元类中之定义了要共享的方法等，这些需要被子类继承。这个模式的实现要点应该是在flyweightFactory中。FlyweightFactory中聚合了多个享元元素的实例，这些实例都可以被重复的使用（不必再新new对象，只需将对象指针指到已经实例化的对象中就可以达到共享之目的了）

   7、facade pattern中，关键就是Facade类在起作用了，它与多个子系统的类相关联，可以使客户端不必关心子系统要处理那些类

   四、对比

  1、可以说享元模式（flyweight）解决的是如何生成许多小的对象的同时节省空间，提高效率。而外观模式（facade）则是决定如何将由多个小的对象组成的子系统用单个对象来表示。

    2、Bridge Pattern和Decorator Pattern从添加功能角度看，我感觉，Bridge Pattern是增加功能的主体和所增加的功能都是在变化，而Decorator Pattern则只有所需的功能在变化，而添加功能的主体并不会发生变化。

    3、Decorator Pattern和Composite Pattern这两个模式从类图结构上看和相似，不过他们针对的问题是有很大区别的，这一点我们只需看下组合模式中的Composite类的方法就可以清楚了。可以说Decorator Pattern是对被装饰的主体进行功能扩大（针对个体扩大），而Composite Pattern则是将主体leaf包含于它的上级机构中（针对机构扩大）

   五、一点感触

  结构型设计模式乍一看上去感觉好多都相似，比如Decorator Pattern能为一个类增加功能，但看组合，桥接等模式似乎也有增加功能的用途，而再一看他们的类图就更生疑惑了（不好分清为什么就这不是在增加功能呢）。我感觉产生这样的原因是面向对象就那主要的三大特征封装继承和多态，而类图也就那五种关系，而我们的设计模式是将这些东西的整合，他们的不同形式形成了解决不同问题的模式。也就是说由于组成模式的材料只有少数几种，在结构和细节实现上肯定会有相似重叠处。这就像不同的生物其爪（人的称之为手）的构成无非就是由肉，骨，毛等组成，但由于其结构形式的不同，它们能做的事情就不同。

    虽然咋一看上去有相似处，但无论是这种相似处还是在形式上的不同之处，我感觉对这些方面的了解应该是为实现某种模式的代码做基础。而要很好的运用各个模式解决不同的问题就要搞清楚每种模式针对问题的不同点和相同点，最好能在今后的实践中找到它们解决问题上的共同点（如果能找到是不是这些模式就可以合并之类的呢？当然不一定，原因是它们必定存在不同点。而不同点才是不同问题的解决核心）

六、总结（从结构上看结构型设计模式）

    每种设计模式都有其针对的问题，而结构型设计模式在解决其问题时必然会带来结构上的扩大，但这种大结构是有必要的，因为这些模式确实和好的解决了问题。那么客观世界都有哪几种主要的结构要求呢?换句话说，是什么让类图结构扩大了呢？我感觉这七类结构型设计模式应该分为三大类。

（一）因类的使用而使结构扩大

1、对先前的类的使用，但接口不兼容（Adapter Pattern）

2、对现有类的使用，但不能直接访问（Proxy Pattern）

3、多方使用同一个类，避免空间的浪费，效率的降低（Flyweight Pattern）

（二）因功能的扩展变化而使结构扩大

1、单个类动态的添加职责（Decorator Pattern）

2、多角度的类功能的变化和扩展（Bridge Pattern）

（三）因机构组织的变化而是结构扩大

1、平级机构的扩大（Facade pattern）

2、分支机构的扩大（Composite Pattern）

   经过总结和对模型代码的实现对这及几种模式的理解加深了一步，但与软件的实际应用的联系尚很肤浅。