结构型模式比较

 

结构型模式概述 
    结构型模式，顾名思义讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模式）。这些结构型模式，它们在某些方面具有很大的相似性，仔细推敲，侧重点却各有不同。 

    Adapter模式通过类的继承或者对象的组合侧重于转换已有的接口；Bridge模式通过将抽象和实现相分离，让它们可以分别独立的变化，它强调的是系统沿着多个方向的变化；Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，它强调的是扩展接口；Composite模式模糊了简单元素和复杂元素的概念，它强调的是一种类层次式的结构；Façade 模式将复杂系统的内部子系统与客户程序之间的依赖解耦，它侧重于简化接口，更多的是一种架构模式；Flyweight模式解决的是由于大量的细粒度对象所造成的内存开销的问题，它与Façade模式恰好相反，关注的重点是细小的对象；Proxy模式为其他对象提供一种代理以控制对这个对象的访问，它注重于增加间接层来简化复杂的问题

Asapte 适配器模式

将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能在一起工作的类可以在一起工作。适配器模式通过继承目标对象并隐含被适配者的真正实现来达到目标操作与被适配器的兼容合作。

外观模式（Facade）

为子系统中的一组接口提供一个一致的界面，定义一个高层接口。这个接口使得这一子系统更容易使用

简化接口，对于复杂子系统或子对象调用封装，从客户程序角度看，只能看到Facade提供的接口。就是对子对象调用的封装，将客户程序对子系统的调用与子系统的变化分离。例如：我们拨打10086，可以办彩铃，手机报，全球通等业务（子对象） ，而10086，则为子对象所使用的一致界面。 

桥接模式Bridge

将抽象部分与现实部分分离，使他们可以独立的变化，减少因变化而带来的代码修改量。

当某个类型具有两个或两个以上的维度变化，通过以继承接口的方式格式变化。

例如，点灯开关，开关的目的是将设备打开或关闭，产生效果的不同

装饰模式 Decorator

动态地给一个对象添加一些额外的职责。 就增加功能来说，要比生成子类更灵活。

主要解决的是继承方式为对象扩展大量功能而造成子类数量你大多的问题

例如： 一幅画，可以直接挂到墙上，也加上框架和玻璃后，在挂到墙上。

组合模式 Composite

将对象组合成树形结构以表示“部分--整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。

解决客户程序与复杂对象容器的解耦。忽略组合对象与单个对象的不同，将统一地使用组合结构中的是有对象

代理模式 Proxy

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

解决直接访问某些对象出现的问题。

 享元模式 Flyweight

运用共享技术有效支持大量细粒度的对象

主要解决由于相同对象数量过大而造成系统内存开销过大的我呢提。实际上是相同的对象引用指向同一个对象空间。

 

 

 适配器与代理模式

从代码的角度看Adapter适配器模式和Proxy代理模式有些类似，前者是解决现有对象在新的环境中所遇到的问题，后者是解决直接访问对象时出现的问题，这两种模式从使用角度看都是解决直接访问对象时出现的问题，只是含义不十分相同。

 

适配器模式和外观模式

适配器模式和外观模式都是对系统的封装，只是适配器是用来适配对象的，而外观是用来配合整个子系统的。

 

外观模式和代理模式

外观模式和代理模式解决问题的侧重点不同，但是它们解决问题的手法却是一样的，即都是引入了间接层的手法，这也是我们软件系统中经常用的一种手法。外观模式虽然侧重于简化接口，但是在某些情况下，外观模式也可以兼任代理模式的责任，例如外观对象有可能是另一个位于另一个地址空间对象的远程代理，这时候我们可以叫做外观代理模式，或者代理外观模式。

 

装饰模式与桥接模式

 这两个模式在一定程度上都是为了减少子类的数目，避免出现复杂的继承关系。但是它们解决的方法却各有不同，装饰模式把子类中比基类中多出来的部分放到单独的类里面，以适应新功能增加的需要，当我们把描述新功能的类封装到基类的对象里面时，就得到了所需要的子类对象，这些描述新功能的类通过组合可以实现很多的功能组合， 桥接模式则把原来的基类的实现化细节抽象出来，在构造到一个实现化的结构中，然后再把原来的基类改造成一个抽象化的等级结构，这样就可以实现系统在多个维度上的独立变化。