程序开发的过程无法从用户那里得获得所有的需求，业务流程是需求中最可能变化的地方，，用户在特殊的时期有不同的需求，从而改变业务流程也是常见的。改变开发过程，有效的应对变化，面向对象思想解决了变化带来的问题。
也看了很多人的总结，有看到“设计模式不是模型，设计模式不是用来严格遵守的，并非一成不变，设计模式最核心的是要素不是设计的结构，而是设计的思想。” 应用设计模式会让程序变得更加灵活，模块之间的耦和度降低，，写出可维护、可扩展、可复用、灵活性好的程序。
创建性模式：当一个系统应该独立于它的产品创建、构成和表示是，应该考虑创建型模式，创建性模式抽象了实例化的过程。
【抽象工厂】
提供一个创建一系列或相关依赖对象的接口，而无需指定他们具体的类。
优点：抽象工厂可以解决多个类型产品创建的问题，易于交换产品系列，抽象工厂模式改变一个应用的具体工厂很容易，只需要改变具体工厂即可。
他让具体的创建实例过程与客户端分离，客户端通过他们的抽象接口操纵实例，产品的具体类名也被具体工厂实现分离，不出现在客户代码中。
缺点：增加功能不方便，如图，不管是增加新的产品还是增加新的品牌都最少增加三个类，并且需要修改AbstractFactory类 ConcretaFactory类。
综上所述：抽象工厂模式适用于交换产品系列，而且是具有良好的设计，使用户不需要关心产品是哪种类型的产品，不适用于增加功能。
【工厂方法】
定义一个用于创建对象的接口，让子类决定实例化哪一类，工厂模式使一个类的实例化延迟到其子类。
工厂方法把工厂职责分类，通常设计就是从工厂方法开始，，需要时在向其他的模式演化，，很好的体现了面向对象中的封装的优点。
缺点是每增加一个产品，需要加一个产品工厂类
【建造者模式】
将一个复杂的对象的构建与它表示分离，使得同样的创建过程可以创建不同的表示。
适用：构建的对象内部结构是稳定的，但表现出来的不一样（比如建小人，人都有头身体 胳膊腿，但有胖瘦高矮之分）
成员：Bulider是用来创建Product对象的各个部件的接口（产品中普遍有的部分，例子中指人的胳膊腿 头 身体）
ConcreteBuilder：具体建造者，实现Builder接口，构造和装配各部件（将画好的个部件组装成具体的人）
Product：具体产品
Direcotr：指挥者，构建使用Bulider接口的对象（根据用具需求构建小人）
public abstract void Buliderhead 运用了抽象方法必须重写的原理（如果想要一个瘦小人，需要写一个瘦小人的类，若这个类中具体参数不够，比如漏掉这个脑袋，会报错）
若想画一个瘦小人，写一个瘦小人的类，继承PersonBulider，写出小人的参数
若想添加一个胖的高的小人，写一个类继承PersonBulider，写出小人的参数就行了，客户端只需要new实例化一个就得到具体的产品了不需要知道中间的制造过程。
【原型模式】
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
适用：在初始化的信息不发生变化的情况下，建立相应数目的原型并克隆他们通常比每次用合适的状态手工实例化更方便一些，它既隐藏了对象创建的细节，动态的获得对象运行时的状态。
【单例模式】
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
上篇博客中写的就是我的理解 不再写了。
【适配器模式】
将一个类的接口装换成客户希望的另一个类的接口。
适用：主要应用于希望复用一些现存的类，但是接口又与复用环境不一致的情况。
原理：通过看结构图可以发现，适配器模式写一个类内部包装需要适配的对象，把需要适配的类的接口转换成目标接口，用目标接口中方法的名字，表面是调用了相同的方法，实际上调用的是需要适配的类中方法。
适配器与代理相比，适配器不需要虚构出一个代表着，只需要应对特定的使用目的，将原来的类进行组合。
【装饰模式】：
动态的给一个对象添加一些额外的职责。就增加功能来说，比生成子类更加灵活。
（装饰模式也是在内部组装完毕，在显示出来，建造者模式不同的是：建造者模式必须全都显示出来，比如画小人必须有头，身体 胳膊腿，而装饰模式有多种组合方案，用装饰模式画小人的话，就允许缺胳膊少腿了。 ）
装饰对象只关心自己的功能，不关心如何被添加到对象连中
适用于：系统需要增加新的功能时，装饰原有类的职责。装饰模式将类的核心职责与装饰功能区分开，方便为已有功能动态的添加更多的功能。
【代理模式】
为其他对象提供一种代理以控制对这个对象的访问。
（a想做一件事，b替a去完成，这件事事实上是同一件事情， a 和b都与这件事情有联系，所以不能将代码只写到任何一方，他们实现了共同的接口。）我的理解：代理模式与其他的主要区别就是实体类需要保留一个引用是代理可以访问实体类，而且代理类可以通过接口完成某事件代替实体，实体类和替代类的关系特殊。
代理模式与外观模式的区别：代理对象代表单一对象而外观对象代表一个子系统，并且代理的客户无法直接访问目标对象，但外观的客户对象可以直接访问子系统的各个对象。
适用：1.远程代理，为一个对象在不同的地址空间提供局部代表。
2.虚拟代理，根据需要创建开销很大的对象，通过它来存放实例化需要很长时间的真实对象。HTML图片框用到代理模式
3.安全代理，用来控制真实的对象是，代理处理另一些事。
【外观模式】
为子系统中的一组接口提供一个一致的界面，定义了一个高层接口，接口使得这一子系统更容易使用
外观模式是常用的模式之一，在设计初期阶段，有意识地将不同的两个层分离，经典的三层架构，需要考虑数据访问层和业务逻辑层，业务逻辑层和表示层的层与层之间建立外观Facade，这样为复杂的子系统提供一个简单的接口，降低耦合度。在开发阶段，子系统因为不断的重构演化而变得越来越复杂，外观模式提供一个简单的接口，减少他们之间的依赖。维护一个遗留的大型系统时，可以开发外观Facade类，使他与原来遗留代码交互复杂的工作。
理解：外观模式与简单工厂模式有点像，都有一个抽象的类或接口；不同点也是很大的，简单工厂中的抽象类中包含的功能行的代码，其他的类继承他获得处理方法，工厂类是用来实例化的，创建实例。外观模式由客户端创建实例，外观模式中的抽象是为了方便交互，这个类是个纽带，他了解所有子系统的方法或属性，传递信息，不具有关于系统功能性的代码。
【桥接模式】
将抽象部分与它的实现部分分离，使它们都可以独立的变化。
（抽象指的是如何完成这项工作，实现指的是抽象中所用步骤地实现。）
优点：继承是一种强耦合关系，父类变，子类必须要变，桥接模式符合合成/聚合复用原则，缓解了强耦合关系，继承好用也不能滥用
适用：观察继承体系中有两个甚至多个方向的变化，那么解耦这些不同方向的变化，通过对象的组合方式，把两个角色之间的继承关系改为组合关系，从而使这两者可以应对各自独立的变化
【组合模式】
Composite模式的意图是“将对象组合成树形结构表示‘整体-部分’的层次结构。Composite使得用户对单个对象和组合对象的使用更具有一致性”。
在Word中我们经常会将一些图元进行“组合”，组合以后的图形还可以向简单图元那样进行移动、变形等等操作；除此以外，在Word中，我们对于一个字符、一个词组、一句话、一个段落，甚至是整篇文章的操作是相同的，我们都可以进行剪切、复制，进行字体与大小的调整，进行颜色的变换。这些例子都是Composite模式的实例，我们将简单的元素组合成复杂的元素，然后还可以像操作简单元素那样操作组合元素。
实现Composite模式的关键是良好设计的接口，人们应该对可能的元素（简单的、组合的）进行分析，并设计出通用的操作。尽可能的保证接口操作对所有元素都是有意义的，否则就应该将那些只对部分元素有意义的操作下放到子类中。
【享元模式】
运用共享技术有效的支持大量细粒度的对象
利用享元模式不会有效的减少信息的数量，因为表达信息的编码数量是一定的，减少的是系统中对象的数量，因为大量的对象被共享。比如，一篇文章中有很多字符，可以对每个字符对象生成一个对象，一篇文章的字数很对的情况下，对象数量也就生成很多，这是，令所有相同的字符共享一个对象，利用享元模式就会大大的减少对象数量，从而节约大量内存。
仅仅是理论上了解了下设计模式，通过看《大话设计模式》发现作者说的生活中很多例子符合设计模式，体会设计模式，理解设计模式中的思想，得通过实践才能感觉到设计模式的优点。
