设计模式
简单工厂模式
用单独的一个类完成创建所有实例，这就是工厂。
public class OperationFactory{
public static Operation createOperate(String op){
Operation operation = null;
switch(op){
case "+":{
operation = new OperationAdd();
}
case "-":{
operation = new OperationSub();
}
// ...
}
}
}
优点：工厂对象类之间解耦
缺点：工厂类和工厂对象类之间存在耦合，新增工厂对象类需要修改工厂类
策略模式
策略模式定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户
单独使用策略模式，实例化对象的过程会落在客户端（switch-case-new过程）。因此可以将策略模式和简单工厂模式结合，将实例化对象的过程放在Context类中
策略模式和简单工厂模式结合使用的好处是，客户端只需要知道Context类
该模式不足的地方在于新增策略仍然要修改Context类中的switch代码块
单一职责原则
单一职责原则：就一个类而言，应该仅有一个引起它变化的原因
例如，游戏逻辑和界面应该分离
开闭原则
开闭原则：软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改
开发人员应该对程序中频繁变化的那些部分做抽象
依赖倒转原则
依赖倒转原则：
- 高层模块不应该依赖低层模块。两个都应该依赖抽象
- 抽象不应该依赖细节，细节应该依赖抽象。换句话说，要针对接口编程，不要对实现编程
针对原则一，子类型必须能够替换掉它们的父类型而不影响软件工程，这样才能真正复用父类，因此高层和低层模块都应该依赖抽象。
针对原则二，例如，电脑主板、CPU、内存、硬盘都是针对接口设计的，如果针对实现来设计，内存就要对应具体的某个品牌的主板，那就会出现换内存要把主板一起换了的尴尬
装饰模式
装饰模式：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更加灵活
代理模式
代理模式：为其它对象提供一种代理以控制对这个对象的访问
使用场景：
- 远程代理。为一个对象在不同的地址空间提供局部代表，这样可以隐藏一个对象存在于不同地址空间的事实。例子：客户端调用代理实现远程访问
- 虚拟代理。使用代理来存放创建开销很大的对象。例子：HTML中的未下载完成的图片框就是虚拟代理，它替代了真实图片
- 安全代理。用来控制真实对象的访问权限
- 智能指引。指调用真实对象时，代理处理另外一些事
工厂方法模式
简单工厂模式违背了开闭原则，于是有了工厂方法模式
工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类
原型模式
原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
模板方法模式
魔棒方法模式：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
迪米特法则
迪米特法则（最少知识原则）：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
迪米特法则的根本思想是类之间的松耦合。
外观模式
外观模式：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
使用场景：
- 在设计阶段，分层架构之间增加Facade，例如表示层和业务逻辑层之间、业务逻辑层和数据访问层之间
- 在开发阶段，随着类越来越多，可以增加Facade降低类调用复杂性
- 在系统重构阶段，可以在系统中增加Facade，Facade调用旧系统代码保证平滑过渡
建造者模式
建造者模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
观察者模式
观察者模式（发布-订阅模式）：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己
使用场景：当一个对象的改变需要同时改变其它对象，且不知道有多少对象需要改变时使用观察者模式
抽象工厂模式
抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类
抽象工厂的优点是只需要更换工厂实例对象，就可以更换一系列产品。缺点是增加产品时需要需改大量类
反射+配置文件+简单工厂可以避免大量修改
状态模式
状态模式：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类
使用场景：当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，可以解决if-else过长的问题
适配器模式
适配器模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
备忘录模式
备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态
使用场景：适用于功能复杂、需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一小部分
组合模式
组合模式：将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性
使用场景：需求中体现部分与整体层次的结构时，以及希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时
迭代器模式
迭代器模式：提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示（foreach语法糖）
单例模式
单例模式：保证一个类仅有一个实例，并提供一个访问它的全局访问点
桥接模式
桥接模式：将抽象部分与它的实现部分分离，使它们都可以独立的变化
使用场景：实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少它们之间的耦合
命令模式
命令模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
职责链模式
职责链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止
中介者模式
中介者模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间地交互。
使用场景：一组对象以定义良好但是复杂地方式进行通信的场合；想定制一个分布在多个类中的行为，而又不想生成太多子类的场合
享元模式
享元模式：运用共享技术有效地支持大量细粒度的对象
使用场景：如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用
解释器模式
解释器模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子
使用场景：当有一个语言需要解释执行，并且可以将该语言中的句子表示为一个抽象语法树时，可使用解释器模式（例如正则表达式，浏览器）
优势：容易地改变和扩展文法
劣势：解释器模式为文法中的每一条规则至少定义了一个类，因此包含许多规则的文法可能难以管理和维护。建议当文法非常复杂时，使用其它技术如语法分析程序或编译器生成器来处理
访问者模式
访问者模式：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作
使用场景：适用于数据结构稳定，算法易于变化
模式总结
- 创建型模式：单例、工厂方法、抽象工厂、建造者、原型
- 结构型模式：适配器、装饰、桥接、组合、享元、代理、外观
- 行为型模式：观察者、模板方法、命令、状态、职责链、解释器、终结者、访问者、策略、备忘录、迭代器
