<大话设计模式>笔记
读完了<大话设计模式>这本书，收获很多，对程序设计有了很多新的理解。将每章模式的大概要点做了些笔记以备查阅，一些设计模式书读完也对其了解得不是很透彻，需要以后在实践中来不断地加深理解吧。读书过程中用Java跟着实践了些部分模式的代码上传到了https://github.com/wanghaoxi3000/design_mode。
设计模式
简单工厂模式
简单工厂模式是属于创建型模式，又叫做静态工厂方法(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图
观察者模式的特点
将一个系统分割成一系列相互协作的类有一个很不好的副作用，需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护，扩展和重用都带来不便。当一个对象的改变需要同时改变其他对象，而且它不知道具体有多少对象待改变时，应该考虑使用观察者模式。 一个抽象模型有两个方面，其中一方面依赖于另一方面，这时使用观察者模式可以将这两者封装在独立的对象中使它们各自独立的改变和复用。 观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使各自的变化都不会影响另一边的变化。
观察者模式的不足与事件委托
观察者模式需要观察者具体类们实现一个通用的通知方法时，当各个观察者无法实现这个通用的通知方法或通知方法不同名时，可使用事件委托，让客户端来指定具体的通知方法。
抽象工厂模式
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
UML图
AbstractProductA和AbstractProductB是两个抽象产品，ProductA1、ProductA2和ProductB1、ProductB2就是对两个抽象产品的具体分类实现。
IFactory是一个抽象工厂接口，它里面应该包含所有产品创建的抽象方法。ConcreteFactory1和ConcreteFactory2就是具体的工厂了。
通常在运行时再创建一个ConcreteFactory类的实例，这个具体的工厂再创建具有特定实现的产品对象，也就是说，为创建不同的产品对象，客户端应使用不同的具体工厂。
抽象工厂的优缺点
优点：
- 具体工厂类在一个应用中只需要初始化时出现一次这就使得改变一个应用的具体工厂变得非常容易
- 它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操作实例，产品的具体类名也被具体工厂实现分离，不会出现在客户代码中
缺点：
- 增加功能时需要改动和增加的类较多
- 客户端程序切换不同工厂时改动较多
状态模式
当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
状态模式主要解决的是控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。当然，如果这个判断逻辑很简单，那就没必要用‘状态模式’了。
UML图
状态模式的好处与用处
状态模式的好处是将与特定状态的相关行为局部化，并且将不同的行为分割开来。 通过将特定的状态相关行为都放入一个对象中，由于所有与状态相关的代码都存于某个ConcreteState中，所以通过定义新的子类可以很容易的增加新的状态和转换。从而消除庞大的条件分支语句。
状态模式同个把各种状态转移逻辑分布到State子类之间，来减少相互之间的依赖，当一个对象的行为取决它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式了。
适配器模式
将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得由于接口不兼容而不能一起工作的那些类可以一起工作。
在软件开发中，系统的数据和行为都正确，但接口不符时，应该考虑用适配器。使控制范围之外的一个原有对象与某个接口匹配。适配器主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。
UML图
慎用适配器模式
当两个类所做的事情相同或相似，但是具有不同的接口时要使用它。但应在双方都不太容易修改的时候再使用适配器模式。尽量使用统一调用同一接口使得更为简单紧凑。
备忘录模式
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
UML图
适用场合
备忘录模式比较适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一小部分时。使用备忘录可以把复杂的对象内部信息屏蔽起来。
组合模式
将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式将使得对象对单个用户对单个对象和组合对象的使用具有一致性。
UML图
适用场合
当需求中是体现部分与整体的层次结构时，以及希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑组合模式了。通过组合模式可以一致地使用组合结构和单个对象。
迭代器模式
提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。 当需要访问一个聚集对象，而且不管这些对象是什么都需要遍历的时候，此时就应该考虑迭代器模式。 当需要对聚集对象进行多种方式遍历时，也可以考虑迭代器模式。 即为遍历不同的聚集结构提供如开始、下一个、是否结束、当前哪一项等统一接口。
迭代器模式分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合内部结构，又可以让外部代码透明地访问集合内部数据。
UML图
单例模式
保证一个类仅有一个实例，并提供一个访问它的全局访问点。 通常我们可以让一个全局变量通过一个对象被访问，但它不能防止你实例化多个对象。一个最好的办法就是，让类的自身负责保存它唯一的实例。这个类可以保证没有其他实例可以被创建，并且提供一个访问该实例的方法。
UML图
桥接模式
将抽象部分与它的实现部分分离,使它们都可以独立地变化。 抽象与它的实现分离，这并不是说，让抽象类与其派生类分离，因为这没有任何意义。实现指的是抽象类和它的派生类用来实现自己的对象。
UML图
命令模式
将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化，对请求派对或记录请求日志，以及支持可撤销的操作。
UML图
命令模式作用
- 可以比较容易设计一个命令队列
- 在需要的情况下，可以较容易地将命令记入日志
- 允许接收请求的一方决定是否要否决请求
- 可以容易的实现对请求的撤销和重做
- 由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类就很容易
职责链模式
使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到一个对象处理它为止。
UML图
职责链的优点
职责链模式使得接收者和发送者都没有对方的明确信息，而且链中的对象自己也并不知道链的结构。结构是职责链可简化对象的相互连接，它们仅需保持一个指向后继者的引用，而不保持它所有的候选接受者的相互连接，它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选者的引用。
中介者模式
用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立的改变它们之间的交互。
享元模式
运用共享技术有效的支持大量细粒度的对象。享元模式可以避免大量非常相似的开销。在程序设计中，有时需要生成大量细粒度的类实例来显示数据。如果发现这些实例除了几个参数外基本都是相同的，有时就能够大幅度地减少需要实例化的类数量。如果把那些参数移到类实例的外面，在方法调用时将它们传递进来，就可以通过共享大幅度的减少单个实例的数目。
UML图
享元模式的应用
如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用，还有就是对象的大多数状态可以是外部状态，如果删除对象的外部状态，那么就可以用相对较少的共享对象取代很多组对象，此时就可以考虑使用享元模式。
解释器模式
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。 解释器所要解决的是一种特定类型的问题发生的频率足够高，那么可能值得将该问题的各个实例表述一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
UML图
访问者模式
表示一个作用于对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
UML图
访问者模式优缺点
访问者模式的目的是要把数据从数据结构中分离出来。一个系统有比较稳定的数据结构，又有易于变化的算法的话，使用访问者模式就是比较合适的，因为访问者模式使算法操作增加变得容易，将有关的行为集中到一个访问者对象中。但缺点也是使增加新的数据结构变得困难了。
设计原则
- 单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因
- 开放-封闭原则：软件实体（类、模块、函数等等）应该可以扩展，但是不可修改
- 依赖倒转原则：高层模块不应该依赖低层模块。两个都应该依赖抽象；抽象不应该依赖细节。细节应该依赖抽象
- 里氏代换原则：子类型必须能够替换掉他们的父类型
- 迪米特法则：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，可以通过第三者转发这个应用
- 合成/聚合复用原则：尽量使用合成、聚合，尽量不要使用类继承