23种设计模式
单例模式
定义：确保一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
类型：创建类模式
类图：
类图知识点：
类图分为三部分，依次是类名、属性、方法
以
<<开头和以>>结尾的为注释信息修饰符
+代表public，-代表private，#代表protected，什么都没有代表包可见。带下划线的属性或方法代表是静态的。
有以下几个要素：
私有的构造方法
指向自己实例的私有静态引用
以自己实例为返回值的静态的公有的方法
单例模式的优点：
在内存中只有一个对象，节省内存空间。
避免频繁的创建销毁对象，可以提高性能。
避免对共享资源的多重占用。
可以全局访问。
适用场景
需要频繁实例化然后销毁的对象。
创建对象时耗时过多或者耗资源过多，但又经常用到的对象。
有状态的工具类对象。
频繁访问数据库或文件的对象。
以及其他我没用过的所有要求只有一个对象的场景。
单例模式注意事项：
只能使用单例类提供的方法得到单例对象，不要使用反射，否则将会实例化一个新对象。
不要做断开单例类对象与类中静态引用的危险操作。
多线程使用单例使用共享资源时，注意线程安全问题。
Results
EagerSingleton,LazySingleton,ThreadSafeSingleton,DoubleCheckedSingleton,DemandHolderSingleton
工厂方法模式
定义：定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类。
类型：创建类模式
类图：
工厂模式根据抽象程度的不同分为三种：简单工厂模式（也叫静态工厂模式）、本文所讲述的工厂方法模式、以及抽象工厂模式。主要优点有：
可以使代码结构清晰，有效地封装变化。
对调用者屏蔽具体的产品类。
降低耦合度。
工厂方法模式有四个要素：
工厂接口。工厂接口是工厂方法模式的核心，与调用者直接交互用来提供产品。在实际编程中，有时候也会使用一个抽象类来作为与调用者交互的接口，其本质上是一样的。
工厂实现。在编程中，工厂实现决定如何实例化产品，是实现扩展的途径，需要有多少种产品，就需要有多少个具体的工厂实现。
产品接口。产品接口的主要目的是定义产品的规范，所有的产品实现都必须遵循产品接口定义的规范。产品接口是调用者最为关心的，产品接口定义的优劣直接决定了调用者代码的稳定性。同样，产品接口也可以用抽象类来代替，但要注意最好不要违反里氏替换原则。
产品实现。实现产品接口的具体类，决定了产品在客户端中的具体行为。
适用场景
首先，作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过
new就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。其次，工厂模式是一种典型的解耦模式，迪米特法则在工厂模式中表现的尤为明显。假如调用者自己组装产品需要增加依赖关系时，可以考虑使用工厂模式。将会大大降低对象之间的耦合度。
再次，由于工厂模式是依靠抽象架构的，它把实例化产品的任务交由实现类完成，扩展性比较好。也就是说，当需要系统有比较好的扩展性时，可以考虑工厂模式，不同的产品用不同的实现工厂来组装。
抽象工厂模式
定义：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类。
类型：创建类模式
类图：
抽象工厂模式与工厂方法模式的区别
工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。
工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类，而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类。
在抽象工厂模式中，有一个产品族的概念：指位于不同产品等级结构中功能相关联的产品组成的家族。
抽象工厂模式的优点
抽象工厂模式除了具有工厂方法模式的优点外，最主要的优点就是可以在类的内部对产品族进行约束。
抽象工厂模式的缺点
产品族的扩展将是一件十分费力的事情，假如产品族中需要增加一个新的产品，则几乎所有的工厂类都需要进行修改。所以使用抽象工厂模式时，对产品等级结构的划分是非常重要的。
适用场景
当需要创建的对象是一系列相互关联或相互依赖的产品族时，便可以使用抽象工厂模式。说的更明白一点，就是一个继承体系中，如果存在着多个等级结构（即存在着多个抽象类），并且分属各个等级结构中的实现类之间存在着一定的关联或者约束，就可以使用抽象工厂模式。假如各个等级结构中的实现类之间不存在关联或约束，则使用多个独立的工厂来对产品进行创建，则更合适一点。
无论是简单工厂模式，工厂方法模式，还是抽象工厂模式，都属于工厂模式，最终目的都是为了解耦。
模板方法模式
定义：定义一个操作中算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变算法的结构即可重定义该算法中的某些特定步骤。
类型：行为类模式
类图：
模版方法模式的结构
抽象方法：父类中只声明但不加以实现，而是定义好规范，然后由它的子类去实现。
模版方法：由抽象类声明并加以实现。一般来说，模版方法调用抽象方法来完成主要的逻辑功能，并且，模版方法大多会定义为
final类型，指明主要的逻辑功能在子类中不能被重写。钩子方法：由抽象类声明并加以实现。但是子类可以去扩展，子类可以通过扩展钩子方法来影响模版方法的逻辑。
抽象类的任务是搭建逻辑的框架，通常由经验丰富的人员编写，因为抽象类的好坏直接决定了程序是否稳定性。
模版方法的优点
容易扩展
便于维护
比较灵活
适用场景
在多个子类拥有相同的方法，并且这些方法逻辑相同时，可以考虑使用模版方法模式。在程序的主框架相同，细节不同的场合下，也比较适合使用这种模式。
建造者模式
定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
类型：创建类模式
类图：
四个要素
产品类：一般是一个较为复杂的对象，也就是说创建对象的过程比较复杂，一般会有比较多的代码量。在本类图中，产品类是一个具体的类，而非抽象类。实际编程中，产品类可以是由一个抽象类与它的不同实现组成，也可以是由多个抽象类与它们的实现组成。
抽象建造者：引入抽象建造者的目的，是为了将建造的具体过程交与它的子类来实现。这样更容易扩展。一般至少会有两个抽象方法，一个用来建造产品，一个是用来返回产品。
建造者：实现抽象类的所有未实现的方法，具体来说一般是两项任务：组建产品；返回组建好的产品。
导演类：负责调用适当的建造者来组建产品，导演类一般不与产品类发生依赖关系，与导演类直接交互的是建造者类。一般来说，导演类被用来封装程序中易变的部分。
建造者模式的优点
首先，建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在导演类中对整体而言可以取得比较好的稳定性。
其次，建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。
建造者模式与工厂模式的区别
总体上，建造者模式仅仅只比工厂模式多了一个“导演类”的角色
与工厂模式相比，建造者模式一般用来创建更为复杂的对象
代理模式
原型模式
定义：用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。
类型：创建类模式
类图：
原型模式主要用于对象的复制，它的核心是就是类图中的原型类Prototype。Prototype类需要具备以下两个条件：
实现
Cloneable接口。在java语言有一个Cloneable接口，它的作用只有一个，就是在运行时通知虚拟机可以安全地在实现了此接口的类上使用clone方法。在java虚拟机中，只有实现了这个接口的类才可以被拷贝，否则在运行时会抛出CloneNotSupportedException异常。重写
Object类中的clone方法。Java中，所有类的父类都是Object类，Object类中有一个clone方法，作用是返回对象的一个拷贝，但是其作用域protected类型的，一般的类无法调用，因此，Prototype类需要将clone方法的作用域修改为public类型。
原型模式的优点及适用场景
使用原型模式创建对象比直接
new一个对象在性能上要好的多，因为Object类的clone方法是一个本地方法，它直接操作内存中的二进制流，特别是复制大对象时，性能的差别非常明显。使用原型模式的另一个好处是简化对象的创建，使得创建对象就像我们在编辑文档时的复制粘贴一样简单。
因为以上优点，所以在需要重复地创建相似对象时可以考虑使用原型模式。比如需要在一个循环体内创建对象，假如对象创建过程比较复杂或者循环次数很多的话，使用原型模式不但可以简化创建过程，而且可以使系统的整体性能提高很多。
原型模式的注意事项
使用原型模式复制对象不会调用类的构造方法。因为对象的复制是通过调用
Object类的clone方法来完成的，它直接在内存中复制数据，因此不会调用到类的构造方法。不但构造方法中的代码不会执行，甚至连访问权限都对原型模式无效。还记得单例模式吗？单例模式中，只要将构造方法的访问权限设置为private型，就可以实现单例。但是clone方法直接无视构造方法的权限，所以，单例模式与原型模式是冲突的，在使用时要特别注意。深拷贝与浅拷贝。
Object类的clone方法只会拷贝对象中的基本的数据类型，对于数组、容器对象、引用对象等都不会拷贝，这就是浅拷贝。如果要实现深拷贝，必须将原型模式中的数组、容器对象、引用对象等另行拷贝。深拷贝与浅拷贝问题中，会发生深拷贝的有java中的8种基本类型以及它们的封装类型，另外还有
String类型。其余的都是浅拷贝。
中介者模式
定义：用一个中介者对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使耦合松散，而且可以独立地改变它们之间的交互。
类型：行为类模式
类图：
中介者模式的结构
中介者模式又称为调停者模式，共分为3部分：
抽象中介者：定义好同事类对象到中介者对象的接口，用于各个同事类之间的通信。一般包括一个或几个抽象的事件方法，并由子类去实现。
中介者实现类：从抽象中介者继承而来，实现抽象中介者中定义的事件方法。从一个同事类接收消息，然后通过消息影响其他同时类。
同事类：如果一个对象会影响其他的对象，同时也会被其他对象影响，那么这两个对象称为同事类。在类图中，同事类只有一个，这其实是现实的省略，在实际应用中，同事类一般由多个组成，它们之间相互影响，相互依赖。同事类越多，关系越复杂。并且，同事类也可以表现为继承了同一个抽象类的一组实现组成。在中介者模式中，同事类之间必须通过中介者才能进行消息传递。
中介者模式的优点
适当地使用中介者模式可以避免同事类之间的过度耦合，使得各同事类之间可以相对独立地使用。
使用中介者模式可以将对象间一对多的关联转变为一对一的关联，使对象间的关系易于理解和维护。
使用中介者模式可以将对象的行为和协作进行抽象，能够比较灵活的处理对象间的相互作用。
适用场景
一般来说，只有对于那种同事类之间是网状结构的关系，才会考虑使用中介者模式。可以将网状结构变为星状结构，使同事类之间的关系变的清晰一些。
命令模式
定义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
类型：行为类模式
类图：
命令模式的结构
Command类：是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute方法用来执行命令。ConcreteCommand类：Command类的实现类，对抽象类中声明的方法进行实现。Client类：最终的客户端调用类。Invoker类：调用者，负责调用命令。Receiver类：接收者，负责接收命令并且执行命令。
命令模式的优缺点
封装性很好：每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。
扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。
缺点，那就是命令如果很多，开发起来就要头疼了。
适用场景
对于大多数请求-响应模式的功能，比较适合使用命令模式，命令模式对实现记录日志、撤销操作等功能比较方便。
责任链模式
定义：使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
类型：行为类模式
类图：
责任连模式的结构
抽象处理类：抽象处理类中主要包含一个指向下一处理类的成员变量
nextHandler和一个处理请求的方法handRequest，handRequest方法的主要主要思想是，如果满足处理的条件，则有本处理类来进行处理，否则由nextHandler来处理。具体处理类：具体处理类主要是对具体的处理逻辑和处理的适用条件进行实现。
责任链模式的优缺点
责任链模式与
if…else…相比，它的耦合性要低一些，因为它把条件判定都分散到了各个处理类中，并且这些处理类的优先处理顺序可以随意设定。责任链模式也有缺点，这与
if…else…语句的缺点是一样的，那就是在找到正确的处理类之前，所有的判定条件都要被执行一遍，当责任链比较长时，性能问题比较严重。
适用场景
假如使用if…else…语句来组织一个责任链时感到力不从心，代码看上去很糟糕时，就可以使用责任链模式来进行重构。
责任链模式其实就是一个灵活版的if…else…语句
装饰模式
策略模式
定义：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。
类型：行为类模式
类图：
策略模式的结构
封装类：也叫上下文，对策略进行二次封装，目的是避免高层模块对策略的直接调用。
抽象策略：通常情况下为一个接口，当各个实现类中存在着重复的逻辑时，则使用抽象类来封装这部分公共的代码，此时，策略模式看上去更像是模版方法模式。
具体策略：具体策略角色通常由一组封装了算法的类来担任，这些类之间可以根据需要自由替换。
策略模式的优缺点
策略模式的主要优点有：
策略类之间可以自由切换
易于扩展
避免使用多重条件
策略模式的缺点主要有两个：
维护各个策略类会给开发带来额外开销
必须对客户端（调用者）暴露所有的策略类，因此，客户端应该知道有什么策略，并且了解各种策略之间的区别，否则，后果很严重。
适用场景
几个类的主要逻辑相同，只在部分逻辑的算法和行为上稍有区别的情况。
有几种相似的行为，或者说算法，客户端需要动态地决定使用哪一种，那么可以使用策略模式，将这些算法封装起来供客户端调用。
适配器模式
迭代器模式
定义：提供一种方法访问一个容器对象中各个元素，而又不暴露该对象的内部细节。
类型：行为类模式
类图：
迭代器模式的结构
抽象容器：一般是一个接口，提供一个
iterator()方法，例如java中的Collection接口，List接口，Set接口等。具体容器：就是抽象容器的具体实现类，比如
List接口的有序列表实现ArrayList，List接口的链表实现LinkList，Set接口的哈希列表的实现HashSet等。抽象迭代器：定义遍历元素所需要的方法，一般来说会有这么三个方法：取得第一个元素的方法
first()，取得下一个元素的方法next()，判断是否遍历结束的方法isDone()（或者叫hasNext()），移出当前对象的方法remove()迭代器实现：实现迭代器接口中定义的方法，完成集合的迭代。
迭代器模式的优缺点
迭代器模式的优点有：
简化了遍历方式，对于对象集合的遍历，还是比较麻烦的，对于数组或者有序列表，我们尚可以通过游标来取得，但用户需要在对集合了解很清楚的前提下，自行遍历对象，但是对于hash表来说，用户遍历起来就比较麻烦了。而引入了迭代器方法后，用户用起来就简单的多了。
可以提供多种遍历方式，比如说对有序列表，我们可以根据需要提供正序遍历，倒序遍历两种迭代器，用户用起来只需要得到我们实现好的迭代器，就可以方便的对集合进行遍历了。
封装性良好，用户只需要得到迭代器就可以遍历，而对于遍历算法则不用去关心。
迭代器模式的缺点：
对于比较简单的遍历（像数组或者有序列表），使用迭代器方式遍历较为繁琐，大家可能都有感觉，像
ArrayList，我们宁可愿意使用for循环和get方法来遍历集合。
适用场景
迭代器模式是与集合共生共死的
组合模式
观察者模式
定义：定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。
类型：行为类模式
类图：
观察者模式的结构
被观察者：从类图中可以看到，类中有一个用来存放观察者对象的
Vector容器（之所以使用Vector而不使用List，是因为多线程操作时，Vector在是安全的，而List则是不安全的），这个Vector容器是被观察者类的核心，另外还有三个方法：attach方法是向这个容器中添加观察者对象；detach方法是从容器中移除观察者对象；notify方法是依次调用观察者对象的对应方法。这个角色可以是接口，也可以是抽象类或者具体的类，因为很多情况下会与其他的模式混用，所以使用抽象类的情况比较多。观察者：观察者角色一般是一个接口，它只有一个
update方法，在被观察者状态发生变化时，这个方法就会被触发调用。具体的被观察者：使用这个角色是为了便于扩展，可以在此角色中定义具体的业务逻辑。
具体的观察者：观察者接口的具体实现，在这个角色中，将定义被观察者对象状态发生变化时所要处理的逻辑。
观察者模式的优点
观察者与被观察者之间是属于轻度的关联关系，并且是抽象耦合的，这样，对于两者来说都比较容易进行扩展。
观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。但同时，这也算是观察者模式一个缺点，由于是链式触发，当观察者比较多的时候，性能问题是比较令人担忧的。并且，在链式结构中，比较容易出现循环引用的错误，造成系统假死。
门面模式
备忘录模式
定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样就可以将该对象恢复到原先保存的状态
类型：行为类
类图：
备忘录模式的结构
发起人：记录当前时刻的内部状态，负责定义哪些属于备份范围的状态，负责创建和恢复备忘录数据。
备忘录：负责存储发起人对象的内部状态，在需要的时候提供发起人需要的内部状态。
管理角色：对备忘录进行管理，保存和提供备忘录。
备忘录模式的优缺点
备忘录模式的优点有：
当发起人角色中的状态改变时，有可能这是个错误的改变，我们使用备忘录模式就可以把这个错误的改变还原。
备份的状态是保存在发起人角色之外的，这样，发起人角色就不需要对各个备份的状态进行管理。
备忘录模式的缺点：
在实际应用中，备忘录模式都是多状态和多备份的，发起人角色的状态需要存储到备忘录对象中，对资源的消耗是比较严重的。
适用场景
如果有需要提供回滚操作的需求，使用备忘录模式非常适合，比如jdbc的事务操作，文本编辑器的Ctrl+Z恢复等。
访问者模式
定义：封装某些作用于某种数据结构中各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
类型：行为类模式
类图：
在访问者模式中，主要包括下面几个角色：
抽象访问者：抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是
visit方法中的参数定义哪些对象是可以被访问的。访问者：实现抽象访问者所声明的方法，它影响到访问者访问到一个类后该干什么，要做什么事情。
抽象元素类：接口或者抽象类，声明接受哪一类访问者访问，程序上是通过
accept方法中的参数来定义的。抽象元素一般有两类方法，一部分是本身的业务逻辑，另外就是允许接收哪类访问者来访问。元素类：实现抽象元素类所声明的
accept方法，通常都是visitor.visit(this)，基本上已经形成一种定式了。结构对象：一个元素的容器，一般包含一个容纳多个不同类、不同接口的容器，如
List、Set、Map等，在项目中一般很少抽象出这个角色。
访问者模式的优点
符合单一职责原则：凡是适用访问者模式的场景中，元素类中需要封装在访问者中的操作必定是与元素类本身关系不大且是易变的操作，使用访问者模式一方面符合单一职责原则，另一方面，因为被封装的操作通常来说都是易变的，所以当发生变化时，就可以在不改变元素类本身的前提下，实现对变化部分的扩展。
扩展性良好：元素类可以通过接受不同的访问者来实现对不同操作的扩展。
适用场景
假如一个对象中存在着一些与本对象不相干（或者关系较弱）的操作，为了避免这些操作污染这个对象，则可以使用访问者模式来把这些操作封装到访问者中去。
假如一组对象中，存在着相似的操作，为了避免出现大量重复的代码，也可以将这些重复的操作封装到访问者中去。
但是，访问者模式并不是那么完美，它也有着致命的缺陷：增加新的元素类比较困难。在元素类数目不确定的情况下，应该慎用访问者模式。所以，访问者模式比较适用于对已有功能的重构
状态模式
解释器模式
定义：给定一种语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中句子。
类型：行为类模式
类图：
解释器模式的结构
抽象解释器：声明一个所有具体表达式都要实现的抽象接口（或者抽象类），接口中主要是一个
interpret()方法，称为解释操作。具体解释任务由它的各个实现类来完成，具体的解释器分别由终结符解释器TerminalExpression和非终结符解释器NonterminalExpression完成。终结符表达式：实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。终结符一半是文法中的运算单元，比如有一个简单的公式
R=R1+R2，在里面R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。非终结符表达式：文法中的每条规则对应于一个非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式
R=R1+R2中，+就是非终结符，解析+的解释器就是一个非终结符表达式。非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式。环境角色：这个角色的任务一般是用来存放文法中各个终结符所对应的具体值，比如
R=R1+R2，我们给R1赋值100，给R2赋值200。这些信息需要存放到环境角色中，很多情况下我们使用Map来充当环境角色就足够了。
解释器模式的优缺点
最显著的优点就是扩展性，修改语法规则只需要修改相应的非终结符就可以了，若扩展语法，只需要增加非终结符类就可以了。
但是，解释器模式会引起类的膨胀，每个语法都需要产生一个非终结符表达式，语法规则比较复杂时，就可能产生大量的类文件，为维护带来非常多的麻烦。同时，由于采用递归调用方法，每个非终结符表达式只关心与自己相关的表达式，每个表达式需要知道最终的结果，必须通过递归方式，无论是面向对象的语言还是面向过程的语言，递归都是一个不推荐的方式。由于使用了大量的循环和递归，效率是一个不容忽视的问题。特别是用于解释一个解析复杂、冗长的语法时，效率是难以忍受的。
适用场景
有一个简单的语法规则，比如一个sql语句，如果我们需要根据sql语句进行rm转换，就可以使用解释器模式来对语句进行解释。
一些重复发生的问题，比如加减乘除四则运算，但是公式每次都不同，有时是a+b-cd，有时是ab+c-d，等等等等个，公式千变万化，但是都是由加减乘除四个非终结符来连接的，这时我们就可以使用解释器模式。