读完了<大话设计模式>这本书，收获很多，对程序设计有了很多新的理解。将每章模式的大概要点做了些笔记以备查阅，一些设计模式书读完也对其了解得不是很透彻，需要以后在实践中来不断地加深理解吧。读书过程中用Java跟着实践了些部分模式的代码上传到了https://github.com/wanghaoxi3000/development/tree/master/Java/JavaSE/DesignPatterns。
设计模式
简单工厂模式
简单工厂模式是属于创建型模式，又叫做静态工厂方法(Static Factory Method)模式，但不属于23种GOF设计模式之一。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。
UML图
策略模式
策略模式定义了算法家族，分别封装起来，让他们之间可以相互替换，此模式让算法的变化，不会影响到使用算法的客户。
UML图
装饰模式
动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
装饰模式是为已有功能动态地添加更多功能的一种方式。当系统需要新功能的时候，是向旧的类添加新的代码。这些新的代码通常创世了原有类的核心职责或主要行为。
UML图
代理模式
为其他对象提供一种代理以控制这个对象的访问。
UML图
代理模式的应用
- 远程代理：为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实。
- 虚拟代理：根据需要创建开销很大的对象。通过它来实例化需要很长时间的真实对象。
- 安全代理：用来控制真实对象访问时的权限。
- 智能指引：当调用真实对象时，代理处理另外一些事。如在访问一个实际对象前，检查是否已经锁定它，以确保其他对象不能改变它。
工厂方法模式
定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到子类。
结构图
UML图
简单工厂与工厂方法的对比
简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对客户端来说，去除了与具体产品的依赖。但新增功能时，需要修改原有的类。不但对扩展开放了，对修改也开放了，违背了开放-封闭原则。
工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂内部的判断逻辑移到了客户端代码来进行。
原型模式
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
UML图
原型模式其实就是从一个对象创建另外一个可定制的对象，而且不需要知道任何创建的细节。
Java提供的克隆接口
Java的所有类都是从java.lang.Object类继承而来的，而Object类提供protected Object clone()方法对对象进行复制，子类当然也可以把这个方法置换掉，提供满足自己需要的复制方法。对象的复制有一个基本问题，就是对象通常都有对其他的对象的引用。当使用Object类的clone()方法来复制一个对象时，此对象对其他对象的引用也同时会被复制一份
Java语言提供的Cloneable接口只起一个作用，就是在运行时期通知Java虚拟机可以安全地在这个类上使用clone()方法。通过调用这个clone()方法可以得到一个对象的复制。由于Object类本身并不实现Cloneable接口，因此如果所考虑的类没有实现Cloneable接口时，调用clone()方法会抛出CloneNotSupportedException异常。
浅克隆和深克隆
无论你是自己实现克隆方法，还是采用Java提供的克隆方法，都存在一个浅度克隆和深度克隆的问题。
- 浅度克隆：只负责克隆按值传递的数据（比如基本数据类型、String类型），而不复制它所引用的对象，换言之，所有的对其他对象的引用都仍然指向原来的对象。
- 深度克隆：除了浅度克隆要克隆的值外，还负责克隆引用类型的数据。那些引用其他对象的变量将指向被复制过的新对象，而不再是原有的那些被引用的对象。换言之，深度克隆把要复制的对象所引用的对象都复制了一遍，而这种对被引用到的对象的复制叫做间接复制。
深度克隆要深入到多少层，是一个不易确定的问题。在决定以深度克隆的方式复制一个对象的时候，必须决定对间接复制的对象时采取浅度克隆还是继续采用深度克隆。因此，在采取深度克隆时，需要决定多深才算深。此外，在深度克隆的过程中，很可能会出现循环引用的问题，必须小心处理。
模板方法模式
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法结构即可重定义该算法的的某些特定步骤
UML图
特点
模板方法模式是通过把不变的行为搬移到超类，去除子类中的重复代码来体现它的优势。当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现，我们通过模板模式把这些行为搬到单一的地方，这样就帮助子类摆脱重复的不变行为的纠缠。
外观模式
为子系统的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使这一子系统更加容易使用。
UML图
何时使用外观模式
- 在设计初期阶段，应该要有意识的将不同的两个层分离，层与层之间建立Facade
- 在开发阶段，子系统往往因为不断重构演化而变得越来越复杂，增加外观Facade可以提供一个简单的接口，减少他们之间的依赖
- 维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，可以为新系统开发一个外观Facade类，让新系统与Facade对象交互，Facade与遗留代码交互完成所有复杂的工作
建造者模式
建造者模式是在当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式。
UML图
何时使用建造者模式
建造者模式主要用于创建一些复杂的对象，这些对象内部构建间的构造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。
建造者模式使得建造代码与表示代码分离，由于建造者隐藏了该产品是如何组装的，所以需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。
观察者模式
观察者模式又称之为发布-订阅模式，定义了一种一对多的依赖关系，让多个观察者对象同时监听一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。
UML图
观察者模式的特点
将一个系统分割成一系列相互协作的类有一个很不好的副作用，需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护，扩展和重用都带来不便。当一个对象的改变需要同时改变其他对象，而且它不知道具体有多少对象待改变时，应该考虑使用观察者模式。
一个抽象模型有两个方面，其中一方面依赖于另一方面，这时使用观察者模式可以将这两者封装在独立的对象中使它们各自独立的改变和复用。
观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使各自的变化都不会影响另一边的变化。
观察者模式的不足与事件委托
观察者模式需要观察者具体类们实现一个通用的通知方法时，当各个观察者无法实现这个通用的通知方法或通知方法不同名时