结构型设计模式是从程序的结构上解决模块之间的耦合问题（好像是句废话），GoF23种设计模式中结构型设计模式有7种，分别是：Adapter适配器模式、Bridge桥接模式、Composite组合模式、Decorator装饰模式、Facade外观模式、Flyweight享元模式和Proxy代理模式。下面分别总结一下这几种模式：
|
设计模式 |
GoF的描述 |
我的理解 |
|
Adapter适配器模式 |
将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的类可以一起工作 |
转换接口，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是，新环境要求的接口是现存对象所不满足的，此时我们可以通过添加一层Adapter对现有的对象加入一些接口，使其适应新的应用环境。 |
|
Bridge桥接模式 |
将抽象部分与实现部分分离，使他们可以独立的变化 |
分离接口（抽象）与其实现，当某个类型具有两个或两个以上的纬度变化（或者说是变化点），通过以继承接口的方式隔离变化，以减少因变化带来的代码的修改量。 |
|
Composite组合模式 |
将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得客户对单个对象和组合对象的使用具有一致性 |
解决客户程序与复杂对象容器的解耦，一类具有“容器特征”的对象——即他们在充当对象的同时，又是其他对象的容器的情况，通过继承统一的接口，我们可以将容器对象及其子对象看成同一类对象使用，以减少对象使用中的复杂度。 |
|
Decorator装饰模式 |
动态的给一个对象添加一些额外的职责。就增加功能而言，Decorator模式比生成子类更为灵活 |
在稳定接口的前提下为对象扩展功能，主要是解决用继承的方式为对象扩展大量功能而造成的子对象数量膨胀的问题 |
|
Facade外观模式 |
为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用 |
简化接口，对于复杂子系统或子对象调用的封装。从客户程序角度看，只能看见Facade提供的接口。换句话说是对子对象调用的封装，将客户程序对子对象的调用与子对象的变化分离。 |
|
Flyweight享元模式 |
运用共享技术有效的支持大量细粒度的对象 |
主要是解决由于相同对象数量过大而造成系统内存开销过大的问题。实际上是相同的对象引用指向同一个对象空间。在使用Flyweight模式前要做一个评估，如果使用不当会适得其反 |
|
Proxy代理模式 |
为其他对象提供一种代理以控制这个对象的访问 |
解决直接访问某些对象是出现的问题，如：访问远程的对象 |
在学习的过程中感觉，从代码的角度看Adapter适配器模式和Proxy代理模式有些类似，Adapter适配器模式是解决现有对象在新的环境中的不足，而Proxy代理模式是解决直接访问对象时出现的问题，这两种模式从使用角度看都是解决直接访问对象时出现的问题，只是含义不十分相同。
GoF23种设计模式中创建型模式有5种，分别是：Singleton单件模式、Abstract Factory抽象工厂模式、Builder生成器模式、Factory Method工厂方法模式、Prototype原形模式。下面分别总结这几种设计模式。
|
设计模式 |
GoF的描述 |
我的理解 |
|
Singleton单件模式 |
保证一个类仅有一个实例，并提供一个该实例全局的访问点 |
控制实体对象的数量 |
|
Abstract Factory抽象工厂模式 |
提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定他们的具体类 |
解决一个系列的对象变化的问题 |
|
Builder生成器模式 |
将一个复杂对象的构建与其表示向分离，使得同样的构建过程可以创建不同的表示 |
应对项目中一些复杂对象的创建工作。所谓“复杂对象”，是指：此对象中还含有其它的子对象 |
|
Factory Method工厂方法模式 |
定义一个用于创建对象的接口，让子类决定实例化那个类。FactoryMethod使得一个类的实例化延迟到子类 |
解决的是“某个对象”的创建工作，由于需求的变化，这个对象常常面临着剧烈的变化，但是这个对象拥有的接口相对稳定。也就是说：枝节常常发生变化，但是枝节与主干的接口相对稳定 |
|
Prototype原形模式 |
使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象 |
某些结构复杂的对象的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有比较稳定一致的接口 |
在学习的过程中，觉得从功能上看Abstract Factory模式和Builder模式容易混淆，Factory Method模式和Prototype模式不好区分。Singleton模式没什么太大的困难。下面就来分析一下前四种模式。
一、Abstract Factory模式和Builder模式：
Abstract Factory是应对一系列对象的创建的问题，正如前面文章中举的例子，对于创建一个汽车对象来说，Abstract Factory模式更关注一系列的对象的创建，或者说是汽车类型中的各个部分，如：Wheel、Engine、Body等等类型的创建。换句话说关注点在这一系列对象上。
Builder是应对一个复杂对象创建的问题，或者说是针对这个复杂对象中的子对象的创建的问题。以汽车的例子来说，我觉得比起Abstract Factory模式，Builder模式相对注重汽车类型（上面所说的“复杂对象”）本身以及其各个部分（Wheel、Engine、Body等等）类型的创建。Builder模式要求这个复杂的类型（汽车）中的各个子类型的结合部分相对稳定，用例子说明就是对于汽车来说，无论用什么配件组装，个个配件的组装方式都一样，有相对稳定的接口。对于这辆车你用什么牌子的Wheel、什么牌子的Engine可能变化会很大很频繁。
二、Factory Method模式和Prototype模式：
开始我觉得这两种模式从功能上讲是一样的（个人观点），都是封装了对对象的创建，只不过Prototype模式是用原型克隆进行拷贝来完成对象的创建，在这之中还应注意浅拷贝和深拷贝的区别。在向同事请教后有点明白。这两种模式在应用场景上还是一定的区别的。
Factory Method模式是重新创建一个对象
Prototype模式是利用现有的对象进行克隆，当两个对象或多个对象雷同的时候，可以考虑用一个已创建的对象去克隆出其余的对象。
以上是对创建型模式的总结，如有不对的观点欢迎指正。
原文地址：http://www.cnblogs.com/abc8023/p/3971229.html
