说明：以下文字来自《设计模式之禅》的笔记

1、工厂方法模式：

定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类

工厂方法模式通用类图
在工厂方法模式中，抽象产品类Product负责定义产品的共性，实现对事物最抽象的定义；Creator为抽象创建类，也就是抽象工厂，具体如何创建产品类是由具体的实现工厂ConcreteCreator通过反射和泛型完成的。
抽象产品类：

public abstract class Product {
     //产品类的公共方法
     public void method1(){
             //业务逻辑处理
     }
     //抽象方法
     public abstract void method2();
}

具体产品类：
具体的产品类可以有多个，都继承于抽象产品类

public class ConcreteProduct1 extends Product {
     public void method2() {
             //业务逻辑处理
     }
}
public class ConcreteProduct2 extends Product {
     public void method2() {
             //业务逻辑处理
     }
}

抽象工厂类：
抽象工厂类负责定义产品对象的产生

public abstract class Creator {
     /*
      * 创建一个产品对象，其输入参数类型可以自行设置
      * 通常为String、Enum、Class等，当然也可以为空
      */
     public abstract <T extends Product> T createProduct(Class<T> c);
}

具体工厂类：
具体如何产生一个产品的对象，是由具体的工厂类实现的

public class ConcreteCreator extends Creator {
     public <T extends Product> T createProduct(Class<T> c){
             Product product=null;
             try {
                    product = (Product)Class.forName(c.getName()).newInstance();
             } catch (Exception e) {
                    //异常处理
             }
             return (T)product;
     }
}

场景类

public class Client {
     public static void main(String[] args) {
             Creator creator = new ConcreteCreator();
             Product product = creator.createProduct(ConcreteProduct1.class);
             /*
              * 继续业务处理
              */
     }
}

该通用代码是一个比较实用、易扩展的框架，读者可以根据实际项目需要进行扩展。

工厂方法模式的使用场景:工厂方法模式是new一个对象的替代品，所以在所有需要生成对象的地方都可以使用，但是需要慎重地考虑是否要增加一个工厂类进行管理，增加代码的复杂度。

工厂方法模式的扩展

• 简单工厂模式（静态工厂模式）：
  一个模块仅需要一个工厂类，没有必要把它产生出来，使用静态的方法就可以了
  简单工厂模式类图
  NvWa类是场景类，里面是main方法
  人类总称

public interface Human {
     //每个人种的皮肤都有相应的颜色
     public void getColor();
     //人类会说话
     public void talk();
}

接口Human是对人类的总称，每个人种都至少具有两个方法，黑色人种、黄色人种、白色人种的代码分别如代码清单8-2、代码清单8-3、代码清单8-4所示。
黑色人种

public class BlackHuman implements Human {
     public void getColor(){
             System.out.println("黑色人种的皮肤颜色是黑色的！");
     }
     public void talk() {
             System.out.println("黑人会说话，一般人听不懂。");
     }
}

黄色人种

public class YellowHuman implements Human {
     public void getColor(){
             System.out.println("黄色人种的皮肤颜色是黄色的！");
     }
     public void talk() {
             System.out.println("黄色人种会说话，一般说的都是双字节。");
     }
}

白色人种

public class WhiteHuman implements Human {
     public void getColor(){
             System.out.println("白色人种的皮肤颜色是白色的！");
     }
     public void talk() {
             System.out.println("白色人种会说话，一般都是但是单字节。");
     }
}

工厂类

public class HumanFactory {
     public static <T extends Human> T createHuman(Class<T> c){
             //定义一个生产出的人种
             Human human=null;
             try {
                     //产生一个人种
                    human = (Human)Class.forName(c.getName()).newInstance();
             } catch (Exception e) {
                    System.out.println("人种生成错误！");
             }
            return (T)human;
     }
}

HumanFactory类仅有两个地方发生变化：去掉继承抽象类，并在createHuman前增加static关键字；工厂类发生变化，也同时引起了调用者NvWa的变化
场景类

public class NvWa {
     public static void main(String[] args) {
             //女娲第一次造人，火候不足，于是白色人种产生了
             System.out.println("--造出的第一批人是白色人种--");
             Human whiteHuman = HumanFactory.createHuman(WhiteHuman.class);
             whiteHuman.getColor();
             whiteHuman.talk();
             //女娲第二次造人，火候过足，于是黑色人种产生了
             System.out.println("\n--造出的第二批人是黑色人种--");
             Human blackHuman = HumanFactory.createHuman(BlackHuman.class);
             blackHuman.getColor();
             blackHuman.talk();
             //第三次造人，火候刚刚好，于是黄色人种产生了
             System.out.println("\n--造出的第三批人是黄色人种--");
             Human yellowHuman = HumanFactory.createHuman(YellowHuman.class);
             yellowHuman.getColor();
             yellowHuman.talk();
     }
}

2、抽象工厂模式：

为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类

抽象工厂模式的通用类图

抽象工厂模式的最大缺点就是产品族扩展非常困难，以通用代码为例，如果要增加一个产品C，也就是说产品家族由原来的2个增加到3个，看看我们的程序有多大改动吧！抽象类AbstractCreator要增加一个方法createProductC()，然后两个实现类都要修改

3、模板方法模式

定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

模板方法模式类图

AbstractClass叫做抽象模板，它的方法分为两类：

• 基本方法
  基本方法也叫做基本操
  作，是由子类实现的方法，并且在模板方法被调用。

• 模板方法
  可以有一个或几个，一般是一个具体方法，也就是一个框架，实现对基本方法的调度，完成固定的逻辑。

  在类图中还有一个角色：具体模板。ConcreteClass1和ConcreteClass2属于具体模板，实现父类所定义的一个或多个抽象方法，也就是父类定义的基本方法在子类中得以实现。
  注意 为了防止恶意的操作，一般模板方法都加上final关键字，不允许被覆写。
  抽象模板类：

public abstract class AbstractClass {
     //基本方法
     protected abstract void doSomething();
     //基本方法
     protected abstract void doAnything();
     //模板方法
     public void templateMethod(){
             /*
              * 调用基本方法，完成相关的逻辑
              */
             this.doAnything();
             this.doSomething();
     }
}

具体模板类：

public class ConcreteClass1 extends AbstractClass {
     //实现基本方法
     protected void doAnything() {
             //业务逻辑处理
     }
     protected void doSomething() {
             //业务逻辑处理
     }
}
public class ConcreteClass2 extends AbstractClass {
     //实现基本方法
     protected void doAnything() {
             //业务逻辑处理
     }
     protected void doSomething() {
             //业务逻辑处理
     }
}

• 场景类：*

public class Client {
     public static void main(String[] args) {
             AbstractClass class1 = new ConcreteClass1();
             AbstractClass class2 = new ConcreteClass2();
             //调用模板方法
             class1.templateMethod();
             class2.templateMethod();
     }
}

注意 抽象模板中的基本方法尽量设计为protected类型，符合迪米特法则，不需要暴露的属性或方法尽量不要设置为protected类型。实现类若非必要，尽量不要扩大父类中的访问权限。

模板方法模式的优点

• 封装不变部分，扩展可变部分
  把认为是不变部分的算法封装到父类实现，而可变部分的则可以通过继承来继续扩展。
• 提取公共部分代码，便于维护
• 行为由父类控制，子类实现
  基本方法是由子类实现的，因此子类可以通过扩展的方式增加相应的功能，符合开闭原则。

模板方法模式的缺点
抽象类负责声明最抽象、最一般的事物属性和方法，实现类完成具体的事物属性和方法。但是模板方法模式却颠倒了，抽象类定义了部分抽象方法，由子类实现，子类执行的结果影响了父类的结果，也就是子类对父类产生了影响，这在复杂的项目中，会带来代码阅读的难度，而且也会让新手产生不适感。

4、代理模式

代理模式也叫做委托模式，为其他对象提供一种代理以控制对这个对象的访问

代理模式通用类图

Subject是RealSubject和Proxy的父类，RealSubject是Proxy的属性。
类图中的三个角色的定义：

• Subject抽象主题角色
  抽象主题类可以是抽象类也可以是接口，是一个最普通的业务类型定义，无特殊要求。
• RealSubject具体主题角色
  也叫做被委托角色、被代理角色。
• Proxy代理主题角色
  也叫做委托类、代理类。它负责对真实角色的应用，把所有抽象主题类定义的方法限制委托给真实主题角色实现，并且在真实主题角色处理完毕前后做预处理和善后处理工作。
  真实主题类

public class RealSubject implements Subject {
     //实现方法
     public void request() {
             //业务逻辑处理
     }
}

RealSubject是一个正常的业务实现类，代理模式的核心就在代理类上

• 代理类*

public class Proxy implements Subject {
     //要代理哪个实现类
     private Subject subject = null;
     //默认被代理者
     public Proxy(){
             this.subject = new Proxy();
     }
     //通过构造函数传递代理者
     public Proxy(Object...objects ){
     }
     //实现接口中定义的方法
     public void request() {
             this.before();
             this.subject.request();
             this.after();
     }
     //预处理
     private void before(){
             //do something
     }
     //善后处理
     private void after(){
             //do something
     }
}

为什么要用代理呀？想想现实世界吧，打官司为什么要找个律师？因为你不想参与中间过程的是是非非，只要完成自己的答辩就成，其他的比如事前调查、事后追查都由律师来搞定，这就是为了减轻你的负担。

动态代理

动态代理是在实现阶段不用关心代理谁，而在运行阶段才指定代理哪一个对象。相对来说，自己写代理类的方式就是静态代理。

动态代理通用类图
两条独立发展的线路。动态代理实现代理的职责，业务逻辑Subject实现相关的逻辑功能，两者之间没有必然的相互耦合的关系。通知Advice从另一个切面切入，最终在高层模块也就是Client进行耦合，完成逻辑的封装任务。
动态代理类

public class GamePlayIH implements InvocationHandler {
     //被代理者
     Class cls =null;
     //被代理的实例
     Object obj = null;
     //我要代理谁
     public GamePlayIH(Object _obj){
             this.obj = _obj;
     }
     //调用被代理的方法
     public Object invoke(Object proxy, Method method, Object[] args)
                    throws Throwable {
//自行添加其他代码
             Object result = method.invoke(this.obj, args);
             return result;
     }
}

动态代理的场景类

public class Client {

     public static void main(String[] args) throws Throwable  {
             //定义一个痴迷的玩家
             IGamePlayer player = new GamePlayer("张三");
             //定义一个handler
             InvocationHandler handler = new GamePlayIH(player);
             //开始打游戏，记下时间戳
             System.out.println("开始时间是：2009-8-25 10:45");
             //获得类的class loader
             ClassLoader cl = player.getClass().getClassLoader();
             //动态产生一个代理者
             IGamePlayer proxy = (IGamePlayer)Proxy.newProxyInstance(cl,new Class[]{IGamePlayer.class},handler);
             //登录
             proxy.login("zhangSan", "password");
             //开始杀怪
             proxy.killBoss();
             //升级
             proxy.upgrade();
             //记录结束游戏时间
             System.out.println("结束时间是：2009-8-26 03:40");
     }
}

jdk动态代理：被代理类必须实现接口。CGLIB可以实现不需要接口也可以实现动态代理的方式。

5、原型模式

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

原型模式的通用类图
原型模式的核心是一个clone方法，通过该方法进行对象的拷贝。Object类提供的方法clone只是拷贝本对象，其对象内部的数组、引用对象等都不拷贝，还是指向原生对象的内部元素地址，这种拷贝就叫做浅拷贝。使用原型模式时，引用的成员变量必须满足两个条件才不会被拷贝：一是类的成员变量，而不是方法内变量；二是必须是一个可变的引用对象，而不是一个原始类型或不可变对象。
原型模式的优点

• 性能优良
  原型模式是在内存二进制流的拷贝，要比直接new一个对象性能好很多
• 逃避构造函数的约束
  直接在内存中拷贝，构造函数是不会执行的

6、责任链模式

使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。

责任链模式通用类图
责任链模式的优点
责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道是谁处理的，处理者可以不用知道请求的全貌，两者解耦，提高系统的灵活性。

责任链模式的缺点
责任链有两个非常显著的缺点：一是性能问题，每个请求都是从链头遍历到链尾，特别是在链比较长的时候，性能是一个非常大的问题。二是调试不很方便，特别是链条比较长，环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂。

7、装饰模式

动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。

装饰模式的通用类图

在类图中，有四个角色需要说明：

• Component抽象构件
  Component是一个接口或者是抽象类，就是定义我们最核心的对象，也就是最原始的对象。注意 在装饰模式中，必然有一个最基本、最核心、最原始的接口或抽象类充当Component抽象构件。
• ConcreteComponent 具体构件
  ConcreteComponent是最核心、最原始、最基本的接口或抽象类的实现，你要装饰的就是它。
• Decorator装饰角色
  一般是一个抽象类，做什么用呢？实现接口或者抽象方法，它里面可不一定有抽象的方法呀，在它的属性里必然有一个private变量指向Component抽象构件。
• 具体装饰角色
  ConcreteDecoratorA和ConcreteDecoratorB是两个具体的装饰类，你要把你最核心的、最原始的、最基本的东西装饰成其他东西。

？？？装饰模式 和 代理模式的区别在哪啊

8、观察者模式

定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。

观察者模式通用类图

观察者模式的几个角色名称：

• Subject被观察者
  定义被观察者必须实现的职责，它必须能够动态地增加、取消观察者。它一般是抽象类或者是实现类，仅仅完成作为被观察者必须实现的职责：管理观察者并通知观察者。
• Observer观察者
  观察者接收到消息后，即进行update（更新方法）操作，对接收到的信息进行处理。
• ConcreteSubject具体的被观察者
  定义被观察者自己的业务逻辑，同时定义对哪些事件进行通知。
• ConcreteObserver具体的观察者
  每个观察在接收到消息后的处理反应是不同，各个观察者有自己的处理逻辑。

9、门面模式

 门面模式（Facade Pattern）也叫做外观模式。要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。

门面模式注重“统一的对象”，也就是提供一个访问子系统的接口，除了这个接口不允许有任何访问子系统的行为发生

门面模式通用类图
Subsystem Classes是子系统所有类的简称，它可能代表一个类，也可能代表几十个对象的集合。简单地说，门面对象是外界访问子系统内部的唯一通道，不管子系统内部是多么杂乱无章，只要有门面对象在，就可以做到“金玉其外，败絮其中”。
门面模式就是通常所说的场景类？？？核心是组合？？？
最佳实践
门面模式是一个很好的封装方法，一个子系统比较复杂时，比如算法或者业务比较复杂，就可以封装出一个或多个门面出来，项目的结构简单，而且扩展性非常好。还有，对于一个较大项目，为了避免人员带来的风险，也可以使用门面模式，技术水平比较差的成员，尽量安排独立的模块，然后把他写的程序封装到一个门面里，尽量让其他项目成员不用看到这些人的代码，看也看不懂，我也遇到过一个“高人”写的代码，private方法、构造函数、常量基本都不用，你要一个public方法，好，一个类里就一个public方法，所有代码都在里面，然后你就看吧，一大坨程序，看着就能把人逼疯。使用门面模式后，对门面进行单元测试，约束项目成员的代码质量，对项目整体质量的提升也是一个比较好的帮助。

10、访问者模式

封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

访问者模式通用类图

• Visitor——抽象访问者
  抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是visit方法的参数定义哪些对象是可以被访问的。
• ConcreteVisitor——具体访问者
  它影响访问者访问到一个类后该怎么干，要做什么事情。
• Element——抽象元素
  接口或者抽象类，声明接受哪一类访问者访问，程序上是通过accept方法中的参数来定义的。
• ConcreteElement——具体元素
  实现accept方法，通常是visitor.visit(this)，基本上都形成了一种模式了。
• ObjectStruture——结构对象
  元素产生者，一般容纳在多个不同类、不同接口的容器，如List、Set、Map等，在项目中，一般很少抽象出这个角色。

11、桥梁模式

桥梁模式也叫做桥接模式将抽象和实现解耦，使得两者可以独立地变化。

桥梁模式的示例类图

在抽象类Corp中聚合了抽象类Product，然后在Corp中调用product的方法。

桥梁模式是一个非常简单的模式，它只是使用了类间的聚合关系、继承、覆写等常用功能，但是它却提供了一个非常清晰、稳定的架构。
桥梁模式很好地体现了开闭原则。

12、适配器模式

将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

适配器模式又叫做变压器模式，也叫做包装模式（Wrapper），但是包装模式可不止一个，还包括装饰模式。

适配器模式通用类图

• Target目标角色
  该角色定义把其他类转换为何种接口，也就是我们的期望接口，例子中的IUserInfo接口就是目标角色。
• Adaptee源角色
  你想把谁转换成目标角色，这个“谁”就是源角色，它是已经存在的、运行良好的类或对象，经过适配器角色的包装，它会成为一个崭新、靓丽的角色。
• Adapter适配器角色
  适配器模式的核心角色，其他两个角色都是已经存在的角色，而适配器角色是需要新建立的，它的职责非常简单：把源角色转换为目标角色，怎么转换？通过继承或是类关联的方式。

13、策略模式

策略模式（Strategy Pattern）也叫政策模式：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。

策略模式通用类图

策略模式使用的就是面向对象的继承和多态机制，非常容易理解和掌握，我们再来看看策略模式的三个角色：

• Context封装角色
  它也叫做上下文角色，起承上启下封装作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化。
• Strategy抽象策略角色
  策略、算法家族的抽象，通常为接口，定义每个策略或算法必须具有的方法和属性。各位看官可能要问了，类图中的AlgorithmInterface是什么意思，嘿嘿，algorithm是“运算法则”的意思，结合起来意思就明白了吧。
• ConcreteStrategy具体策略角色
  实现抽象策略中的操作，该类含有具体的算法。

策略模式的优点

• 避免使用多重条件判断
  如果没有策略模式，我们想想看会是什么样子？一个策略家族有5个策略算法，一会要使用A策略，一会要使用B策略，怎么设计呢？使用多重的条件语句？多重条件语句不易维护，而且出错的概率大大增强。使用策略模式后，可以由其他模块决定采用何种策略，策略家族对外提供的访问接口就是封装类，简化了操作，同时避免了条件语句判断。
• 扩展性良好
  在现有的系统中增加一个策略太容易了，只要实现接口就可以了，其他都不用修改，类似于一个可反复拆卸的插件，这大大地符合了OCP原则。
  策略模式的缺点
• 策略类数量增多
  每一个策略都是一个类，复用的可能性很小，类数量增多。
• 所有的策略类都需要对外暴露
  上层模块必须知道有哪些策略，然后才能决定使用哪一个策略，这与迪米特法则是相违背的，我只是想使用了一个策略，我凭什么就要了解这个策略呢？那要你的封装类还有什么意义？这是原装策略模式的一个缺点，幸运的是，我们可以使用其他模式来修正这个缺陷，如工厂方法模式、代理模式或享元模式。

14、单例模式

使用场景
在一个系统中，要求一个类有且仅有一个对象，如果出现多个对象就会出现“不良反应”，可以采用单例模式，具体的场景如下：
1、创建一个对象需要消耗的资源过多，如要访问IO和数据库等资源；
2、需要定义大量的静态常量和静态方法（如工具类）的环境，可以采用单例模式（当然，也可以直接声明为static的方式）。
单例模式通用代码（饿汉式，线程安全）

public class Singleton {
     private static final Singleton singleton = new Singleton();
     //限制产生多个对象
     private Singleton(){
     }
     //通过该方法获得实例对象
     public static Singleton getSingleton(){
             return singleton;
     }
     //类中其他方法，尽量是static
     public static void doSomething(){
     }
}

线程不安全的单例（懒汉式单例，加了双检锁也不推荐使用）

public class Singleton {
     private static Singleton singleton = null;
     //限制产生多个对象
     private Singleton(){
     }
     //通过该方法获得实例对象
     public static Singleton getSingleton(){
             if(singleton == null){
                    singleton = new Singleton();
             }
             return singleton;
     }
}