单例模式

1. 单例模式简介

　　单例模式是一种对象创建模式，它用于产生一个对象的具体实例，并确保系统中有且只有该对象的实例。

　　Java 语言中的单例模式是一个虚拟机范围，因为装载类的功能是虚拟机提供的，所以一个虚拟机实例在通过自己的 ClassLoad 装载实现单例模式的类的时候，只会创建一个类的实例。

单例模式的核心在于通过一个接口返回唯一的对象实例，并排除其他外部能够创建新对象的可能。那么，首要的问题就是把创建对象的权限回收，让对象自身来负责其实例的创建工作，然后通过该对象提供的外部可访问接口获取该对象的实例。

一般在两种场景下会考虑使用单例（Singleton）模式：

产生某对象会消耗过多的资源，为避免频繁地创建与销毁对象对资源的浪费。如：对数据库的操作、访问IO、线程池（threadpool）、网络请求等。如对配置文件的读取。
某种类型的对象应该有且只有一个。如果制造出多个这样的实例，可能导致：程序行为异常、资源使用过量、结果不一致等问题。如果多人能同时操作一个文件，又不进行版本管理，必然会有的修改被覆盖，所以：一个系统只能有：一个窗口管理器或文件系统，计时工具或 ID（序号）生成器，缓存（cache），处理偏好设置和注册表（registry）的对象，日志对象。

单例模式的优点：可以减少系统内存开支，减少系统性能开销，减轻垃圾回收的压力，同时还能避免对资源的多重占用、同时操作。
单例模式的缺点：扩展很困难，容易引发内存泄露，测试困难，一定程度上违背了单一职责原则，进程被杀时可能有状态不一致问题。

2. 单例模式的实现

　　我们经常看到的单例模式，按加载时机可以分为：饿汉方式和懒汉方式；按实现的方式，有：双重检查加锁，内部类方式和枚举方式等等。另外还有一种通过Map容器来管理单例的方式。它们有的效率很高，有的节省内存，有的实现得简单漂亮，还有的则存在严重缺陷，它们大部分使用的时候都有限制条件。下面我们来分析下各种写法的区别，辨别出哪些是不可行的，哪些是推荐的，最后为大家筛选出几个最值得我们适时应用到项目中的实现方式。

　　因为下面要讨论的单例写法比较多，筛选过程略长，结论先行：无论以哪种形式实现单例模式，本质都是使单例类的构造函数对其他类不可见，仅提供获取唯一一个实例的静态方法，必须保证这个获取实例的方法是线程安全的，并防止反序列化、反射、克隆（多个类加载器、分布式系统）等多种情况下重新生成新的实例对象。至于选择哪种实现方式则取决于项目自身情况，如：是否是复杂的高并发环境、JDK 是哪个版本的、对单例对象资源消耗的要求等。

上表中仅列举那些线程安全的实现方式，永远不要使用线程不安全的单例！
另有使用容器管理单例的方式，属于特殊的应用情况，下文单独讨论。

直观一点，再上一张图：

此四种单例实现方式都是线程安全的，是实现单例时不错的选择

下面就来具体谈一下各种单例实现方式及适用范围。

饿汉式

　　一种简单的单例实现方案如下：

public class Singleton {

    private static Singleton singleton = new Singleton();

    private Singleton() {
        // ToDo  do somthing here
    }

    public static Singleton getInstance() {
        return singleton;
    }
}

　　Singleton 类的构造函数被声明为 private，确保了其不能在类的外部通过 new 关键字创建新的对象。也就是说，这样使得该单例类不会在系统的其他代码中被实例化。

　　但是，由于使用了 static 作为字段 singleton 的修饰符，那么，在类加载的准备阶段就会初始化 singleton 对象。如果 Singleton 在系统中还扮演其他角色，那么在系统中任何使用这个单例类的地方都会初始化 singleton 对象，无论此时 singleton 对象是否被使用到

public class Singleton {

    private static Singleton singleton = new Singleton();

    private Singleton() {
        // ToDo  do somthing here
        System.out.println("Singleton is create");
    }

    public static Singleton getInstance() {
        return singleton;
    }

    public static void printSomething() {
        System.out.println("print in Singleton");
    }

    public static void main(String[] args) {
        Singleton.printSomething();
    }
}

　　程序输出：
Singleton is create
print in Singleton

　　也就是说，该方法创建的单例类会在第一次引用该类的时候就创建对象实例，而不管实际是否需要。这样写的好处在于结构简单，但是达不到按需加载的目的。

懒汉式（线程不安全）

　　为了解决上述单例类无法按需加载的问题，我们对上述代码做如下改动：

public class Singleton {

    private static Singleton singleton = null;

    private Singleton() {
        // ToDo  do somthing here
    }

    public static synchronized Singleton getInstance() {
        return singleton == null ? singleton = new Singleton() : singleton;
    }
}

　　代码中对静态成员变量 singleton 初始化赋值 null，确保类加载时没有额外的负载，然后在获取 Singleton 对象实例的时候（getInstance（））通过 singleton == null ? singleton = new Singleton() : singleton; 实现 singleton对象的按需加载。

　　但是此时如果有多个线程对 getInstance() 方法进行调用，那么由于线程的同步问题，那么很有可能会出现重复创建 Singleton 对象的情况。这种极端情况的出现是由于，在多线程环境中，如果线程 A 调用 getInstance() 方法获取对象实例，Singleton 对象正在创建，而此时线程 B 也恰巧调用 getInstance()，那么在线程 B 中可能会判断 singleton对象为 null，也会创建一个新的 Singleton 对象。

　　所以，在多线程环境中，一种更为严格的单例模式应该是线程安全的：

双重校验锁

public class Singleton {

    private static volatile Singleton singleton = null;

    private Singleton() {
        // ToDo  do somthing here
    }

    public static Singleton getInstance() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

　　上面这种写法被称为双重检查锁，也就是说，在 getInstance() 方法中进行了两次 null 判断。如此一来，在对 Singleton.class 对象加锁前进行一次 null 判断可以避免绝大多数的加锁操作，进而提升代码的执行效率。

　　但是，由于在 JDK 1.5 之前的版本中，由于对禁止指令重排优化并不支持（volatile 关键字确保编译器禁止指令重排优化），所以双重检查锁的单例模式也是无法保证线程安全的。

　　在多线程环境中，由于编译器只保证程序执行结果与源代码相同，但是不保证实际指令的执行顺序与源代码相同。所以会出现在多线程环境下调用 getInstance() 方法时会产生乱序的问题。这就是编译器对指令做了指令重排序优化造成的。而 volatile 关键字的作用则是通知编译器不执行指令重排序优化。

　　singleton = new Singleton(); 是一条简单的初始化并赋值的操作，但是它不是一个原子操作。对于编译器来说，执行该行代码大致需要做三件事情：　　A：为对象分配内存；　　B：调用 Singleton 的构造函数初始化对象；　　C: 将引用 singleton 指向新分配的内存空间

　　那么，操作 B 依赖于操作 A，操作 C 依赖于操作 B，如果这时候有两个线程进入，线程A发生了指令重拍，先执行了A，然后执行了C，这时候线程B也进入，发现对象已经存在了不为空，于是开始接下来的操作，但是这时候实际上对象并未初始化，就会报错

静态内部类单例模式

　　双重检查锁存在的问题的直接原因是初始化一个对象并使一个引用指向它的过程并不是 volatile的，导致了可能会出现引用指向了对象并没有初始化完成的那块堆内存。即便是在 JDK 1.5之后可以通过使用 volatile 关键字解决问题，但是我们可以通过更为优雅，效率更高的方式实现单例模式：

public class Singleton {

    private Singleton() {
    }

    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }

    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
}

工厂模式

一工厂模式介绍

1.1 工厂模式的分类：

（1）简单工厂（Simple Factory）模式，又称静态工厂方法模式（Static Factory Method Pattern）。

（2）工厂方法（Factory Method）模式，又称多态性工厂（Polymorphic Factory）模式或虚拟构造子（Virtual Constructor）模式；

（3）抽象工厂（Abstract Factory）模式，又称工具箱（Kit 或Toolkit）模式。

1.2 在开源框架中的使用

举两个比较常见的例子(我暂时可以准确想到的，当然还有很多很多):

(1)Spring中通过getBean("xxx")获取Bean；

(2) Java消息服务JMS中(下面以消息队列ActiveMQ为例子)

关于消息队列ActiveMQ的使用可以查看：消息队列ActiveMQ的使用详解

// 1、创建一个连接工厂对象，需要指定服务的ip及端口。
ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://192.168.25.155:61616");
// 2、使用工厂对象创建一个Connection对象。
Connection connection = connectionFactory.createConnection();

1.3 为什么要用工厂模式

(1)解耦：把对象的创建和使用的过程分开

(2)降低代码重复: 如果创建某个对象的过程都很复杂，需要一定的代码量，而且很多地方都要用到，那么就会有很多的重复代码。

(3)降低维护成本：由于创建过程都由工厂统一管理，所以发生业务逻辑变化，不需要找到所有需要创建某个对象的地方去逐个修正，只需要在工厂里修改即可，降低维护成本。

关于工厂模式的作用，Mark一篇文章：blog.csdn.net/lovelion/ar…

二简单工厂模式

2.1 介绍

严格的说，简单工厂模式并不是23种常用的设计模式之一，它只算工厂模式的一个特殊实现。简单工厂模式在实际中的应用相对于其他2个工厂模式用的还是相对少得多，因为它只适应很多简单的情况。

最重要的是它违背了我们在概述中说的开放-封闭原则（虽然可以通过反射的机制来避免，后面我们会介绍到）。因为每次你要新添加一个功能，都需要在生switch-case 语句（或者if-else 语句）中去修改代码，添加分支条件。

2.2 适用场景

（1）需要创建的对象较少。

（2）客户端不关心对象的创建过程。

2.3 简单工厂模式角色分配：

工厂(Factory)角色:简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。
抽象产品(Product)角色:简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。
具体产品(Concrete Product)角色:简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。

2.4 简单工厂实例

创建一个可以绘制不同形状的绘图工具，可以绘制圆形，正方形，三角形，每个图形都会有一个draw()方法用于绘图.

（1）创建Shape接口

public interface Shape {
    void draw();
}
（2）创建实现该接口的具体图形类
圆形

public class Circle implements Shape {
    public Circle() {
        System.out.println("Circle");
    }
    @Override
    public void draw() {
        System.out.println("Draw Circle");
    }
}
长方形
public class Rectangle implements Shape {
    public Rectangle() {
        System.out.println("Rectangle");
    }
    @Override
    public void draw() {
        System.out.println("Draw Rectangle");
    }
}
正方形

public class Square implements Shape {
    public Square() {
        System.out.println("Square");
    }

    @Override
    public void draw() {
        System.out.println("Draw Square");
    }
}
（3）创建工厂类：
public class ShapeFactory {

    // 使用 getShape 方法获取形状类型的对象
    public static Shape getShape(String shapeType) {
        if (shapeType == null) {
            return null;
        }
        if (shapeType.equalsIgnoreCase("CIRCLE")) {
            return new Circle();
        } else if (shapeType.equalsIgnoreCase("RECTANGLE")) {
            return new Rectangle();
        } else if (shapeType.equalsIgnoreCase("SQUARE")) {
            return new Square();
        }
        return null;
    }
}
（4）测试方法：
public class Test {

    public static void main(String[] args) {

        // 获取 Circle 的对象，并调用它的 draw 方法
        Shape circle = ShapeFactory.getShape("CIRCLE");
        circle.draw();

        // 获取 Rectangle 的对象，并调用它的 draw 方法
        Shape rectangle = ShapeFactory.getShape("RECTANGLE");
        rectangle.draw();

        // 获取 Square 的对象，并调用它的 draw 方法
        Shape square = ShapeFactory.getShape("SQUARE");
        square.draw();
    }
}

输出结果：
Circle
Draw Circle
Rectangle
Draw Rectangle
Square
Draw Square

这样的实现有个问题，如果我们新增产品类的话，就需要修改工厂类中的getShape（）方法，这很明显不符合开放-封闭原则。

2.5 使用反射机制改善简单工厂

将工厂类改为下面的形式：

package factory_pattern;

/**
 * 利用反射解决简单工厂每次增加新了产品类都要修改产品工厂的弊端
 * 
 * @author Administrator
 *
 */
public class ShapeFactory2 {
    public static Object getClass(Class<? extends Shape> clazz) {
        Object obj = null;

        try {
            obj = Class.forName(clazz.getName()).newInstance();
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }

        return obj;
    }
}
测试方法：
package factory_pattern;

public class Test2 {
    public static void main(String[] args) {

        Circle circle = (Circle) ShapeFactory2.getClass(factory_pattern.Circle.class);
        circle.draw();

        Rectangle rectangle = (Rectangle) ShapeFactory2.getClass(factory_pattern.Rectangle.class);
        rectangle.draw();

        Square square = (Square) ShapeFactory2.getClass(factory_pattern.Square.class);
        square.draw();
    }

}

这种方式的虽然符合了开放-关闭原则，但是每一次传入的都是产品类的全部路径，这样比较麻烦。如果需要改善的话可以通过反射+配置文件的形式来改善，这种方式使用的也是比较多的。

三、工厂方法模式

3.1 介绍

工厂方法模式应该是在工厂模式家族中是用的最多模式，一般项目中存在最多的就是这个模式。

工厂方法模式是简单工厂的仅一步深化，在工厂方法模式中，我们不再提供一个统一的工厂类来创建所有的对象，而是针对不同的对象提供不同的工厂。也就是说每个对象都有一个与之对应的工厂。

3.2 适用场景

一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。
一个类通过其子类来指定创建哪个对象：在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏
将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无需关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。

3.3 工厂方法模式角色分配：

抽象工厂(Abstract Factory)角色：是工厂方法模式的核心，与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。
具体工厂(Concrete Factory)角色：这是实现抽象工厂接口的具体工厂类，包含与应用程序密切相关的逻辑，并且受到应用程序调用以创建某一种产品对象。
抽象产品(AbstractProduct)角色：工厂方法模式所创建的对象的超类型，也就是产品对象的共同父类或共同拥有的接口。
具体产品(Concrete Product)角色：这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创建，它们之间往往一一对应

3.4 工厂方法模式实例

上面简单工厂例子中的图形接口以及相关图像实现类不变。我们只需要增加一个工厂接口以及实现这个接口的工厂类即可。

(1)增加一个工厂接口：
public interface Factory {
    public Shape getShape();
}
（2）增加相关工厂类:
圆形工厂类
public class CircleFactory implements Factory {

    @Override
    public Shape getShape() {
        // TODO Auto-generated method stub
        return new Circle();
    }

}
长方形工厂类
public class RectangleFactory implements Factory{

    @Override
    public Shape getShape() {
        // TODO Auto-generated method stub
        return new Rectangle();
    }

}
圆形工厂类
public class SquareFactory implements Factory{

    @Override
    public Shape getShape() {
        // TODO Auto-generated method stub
        return new Square();
    }

}
（3）测试：
public class Test {

    public static void main(String[] args) {
        Factory circlefactory = new CircleFactory();
        Shape circle = circlefactory.getShape();
        circle.draw();
    }

}
输出结果：
Circle
Draw Circle

四、抽象工厂模式

4.1 介绍

在工厂方法模式中，其实我们有一个潜在意识的意识。那就是我们生产的都是同一类产品。抽象工厂模式是工厂方法的仅一步深化，在这个模式中的工厂类不单单可以创建一种产品，而是可以创建一组产品。

抽象工厂应该是比较最难理解的一个工厂模式了。

4.2 适用场景

和工厂方法一样客户端不需要知道它所创建的对象的类。
需要一组对象共同完成某种功能时，并且可能存在多组对象完成不同功能的情况。（同属于同一个产品族的产品）
系统结构稳定，不会频繁的增加对象。（因为一旦增加就需要修改原有代码，不符合开闭原则）

4.3 抽象工厂方法模式角色分配：

抽象工厂（AbstractFactory）角色：是工厂方法模式的核心，与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。
具体工厂类（ConreteFactory）角色：这是实现抽象工厂接口的具体工厂类，包含与应用程序密切相关的逻辑，并且受到应用程序调用以创建某一种产品对象。
抽象产品（Abstract Product）角色：工厂方法模式所创建的对象的超类型，也就是产品对象的共同父类或共同拥有的接口。
具体产品（Concrete Product）角色：抽象工厂模式所创建的任何产品对象都是某一个具体产品类的实例。在抽象工厂中创建的产品属于同一产品族，这不同于工厂模式中的工厂只创建单一产品，我后面也会详解介绍到。

。

4.4 抽象工厂的工厂和工厂方法中的工厂有什么区别呢？

抽象工厂是生产一整套有产品的（至少要生产两个产品)，这些产品必须相互是有关系或有依赖的，而工厂方法中的工厂是生产单一产品的工厂。

4.5 抽象工厂模式实例

不知道大家玩过穿越火线或者吃鸡这类游戏了吗，游戏中存在各种枪。我们假设现在存在AK、M4A1两类枪，每一种枪对应一种子弹。我们现在这样考虑生产AK的工厂可以顺便生产AK使用的子弹，生产M4A1的工厂可以顺便生产M4A1使用的子弹。（AK工厂生产AK系列产品包括子弹啊，AK枪的类型啊这些，M4A1工厂同理）

（1）创建相关接口：
枪
public interface Gun {
    public void shooting();
}
子弹
public interface Bullet {
    public void load();
}
（2）创建接口对应实现类：
AK类
public class AK implements Gun{

    @Override
    public void shooting() {
        System.out.println("shooting with AK");

    }

}
M4A1类
public class M4A1 implements Gun {

    @Override
    public void shooting() {
        System.out.println("shooting with M4A1");

    }

}
AK子弹类
public class AK_Bullet implements Bullet {

    @Override
    public void load() {
        System.out.println("Load bullets with AK");
    }

}
M4A1子弹类
public class M4A1
_Bullet implements Bullet {

    @Override
    public void load() {
        System.out.println("Load bullets with M4A1");
    }

}
（3）创建工厂接口
public interface Factory {
    public Gun produceGun();
    public Bullet produceBullet();
}
（4）创建具体工厂
生产AK和AK子弹的工厂
public class AK_Factory implements Factory{

    @Override
    public Gun produceGun() {
        return new AK();
    }

    @Override
    public Bullet produceBullet() {
        return new AK_Bullet();
    }

}
生产M4A1和M4A1子弹的工厂
public class M4A1_Factory implements Factory{

    @Override
    public Gun produceGun() {
        return new M4A1();
    }

    @Override
    public Bullet produceBullet() {
        return new M4A1_Bullet();
    }

}
（5）测试
public class Test {

    public static void main(String[] args) {  

     Factory factory;
     Gun gun;
     Bullet bullet;

     factory =new AK_Factory();
     bullet=factory.produceBullet();
     bullet.load();
     gun=factory.produceGun();
     gun.shooting(); 

    }

}
输出结果：
Load bullets with AK
shooting with AK

策略模式

一、什么是策略模式

　　策略这个词应该怎么理解，打个比方说，我们出门的时候会选择不同的出行方式，比如骑自行车、坐公交、坐火车、坐飞机、坐火箭等等，这些出行方式，每一种都是一个策略。

　　再比如我们去逛商场，商场现在正在搞活动，有打折的、有满减的、有返利的等等，其实不管商场如何进行促销，说到底都是一些算法，这些算法本身只是一种策略，并且这些算法是随时都可能互相替换的，比如针对同一件商品，今天打八折、明天满100减30，这些策略间是可以互换的。

策略模式（Strategy） ，定义了一组算法，将每个算法都封装起来，并且使它们之间可以互换。UML结构图如下：

　　其中，Context是上下文，用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用；Strategy是策略类，用于定义所有支持算法的公共接口；ConcreteStrategy是具体策略类，封装了具体的算法或行为，继承于Strategy。

1. Context上下文

　　Context上下文角色，也叫Context封装角色，起承上启下的作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化。

 1 public class Context {
 2     
 3     Strategy strategy;
 4     
 5     public Context(Strategy strategy) {
 6         this.strategy = strategy;
 7     }
 8     
 9     //上下文接口
10     public void contextInterface() {
11         strategy.algorithmInterface();
12     }
13 
14 }

2. 策略角色

　　抽象策略角色，是对策略、算法家族的抽象，通常为接口，定义每个策略或算法必须具有的方法和属性。algorithm是“运算法则”的意思。

1 public abstract class Strategy {
2     
3     //算法方法
4     public abstract void algorithmInterface();
5 
6 }

3. 具体策略角色

　　用于实现抽象策略中的操作，即实现具体的算法，下方用print代替。测试类共3个ConcreteStrategy，其它两个类与ConcreteStrategyA同理，就不再赘述了。

1 public class ConcreteStrategyA extends Strategy {
2 
3     @Override
4     public void algorithmInterface() {
5         System.out.println("算法A实现");
6     }
7 
8 }

4. Client客户端

　　下面依次更换策略，测试一下策略模式。

 1 public class Client {
 2     
 3     public static void main(String[] args) {
 4         Context context;
 5         
 6         context = new Context(new ConcreteStrategyA());
 7         context.contextInterface();
 8         
 9         context = new Context(new ConcreteStrategyB());
10         context.contextInterface();
11         
12         context = new Context(new ConcreteStrategyC());
13         context.contextInterface();
14     }
15 
16 }

　　运行结果如下：

二、策略模式的应用

　　1. 何时使用

一个系统有许多类，而区分它们的只是他们直接的行为时

　　2. 方法

将这些算法封装成一个一个的类，任意的替换

　　3. 优点

算法可以自由切换
避免使用多重条件判断（如果不用策略模式我们可能会使用多重条件语句，不利于维护）
扩展性良好，增加一个策略只需实现接口即可

　　4. 缺点

策略类数量会增多，每个策略都是一个类，复用的可能性很小
所有的策略类都需要对外暴露

　　5. 使用场景

多个类只有算法或行为上稍有不同的场景
算法需要自由切换的场景
需要屏蔽算法规则的场景

　　6. 应用实例

出行方式，自行车、汽车等，每一种出行方式都是一个策略
商场促销方式，打折、满减等
Java AWT中的LayoutManager，即布局管理器

　　7. 注意事项

如果一个系统的策略多于四个，就需要考虑使用混合模式来解决策略类膨胀的问题

三、策略模式的实现

　　下面就以商场促销为例使用策略模式实现商场促销算法。UML图如下：

　　1. 上下文类

　　首先声明一个CashSuper对象，通过构造方法，传入具体的收费策略，getResult()方法的功能为根据收费策略的不同获得计算结果。

 1 public class CashContext {
 2     
 3     private CashSuper cashSuper;
 4     
 5     public CashContext(CashSuper cashSuper) {
 6         this.cashSuper = cashSuper;
 7     }
 8     
 9     public double getResult(double money) {
10         return cashSuper.acceptCash(money);
11     }
12 
13 }

　　2. 现金收费抽象类

　　策略类，为抽象类，抽象出收费的方法供子类实现。
1 public abstract class CashSuper {
2     
3     public abstract double acceptCash(double money);
4 
5 }

　　3. 正常收费子类

　　没有任何活动的情况，正常收费，返回原价。

1 public class CashNormal extends CashSuper {
2 
3     @Override
4     public double acceptCash(double money) {
5         return money;
6     }
7 
8 }

　　4. 打折收费子类

　　打折活动，根据折扣返回打折后的价格。

 1 public class CashRebate extends CashSuper {
 2     
 3     private double moneyRebate = 1;    //折扣
 4     
 5     public CashRebate(double moneyRebate) {
 6         this.moneyRebate = moneyRebate;
 7     }
 8 
 9     @Override
10     public double acceptCash(double money) {
11         return money * moneyRebate;
12     }
13 
14 }

　　5. 返利收费子类

　　返利活动，输入返利条件和返利值，比如满300返100，moneyCoditation为300，moneyReturn为100。

result = money - Math.floor(money / moneyConditation) * moneyReturn; 的意思为，如果当前金额大于等于返利条件，则使用当前金额减去返利值。

 1 public class CashReturn extends CashSuper {
 2 
 3     private double moneyConditation = 0.0;    //返利条件
 4     private double moneyReturn = 0.0d;    //返利值
 5     
 6     public CashReturn(double moneyConditation, double moneyReturn) {
 7         this.moneyConditation = moneyConditation;
 8         this.moneyReturn = moneyReturn;
 9     }
10 
11     @Override
12     public double acceptCash(double money) {
13         double result = money;
14         
15         if (money >= moneyConditation) {
16             result = money - Math.floor(money / moneyConditation) * moneyReturn;
17         }
18         
19         return result;
20     }
21 
22 }

　　6. Client客户端

　　下面写一个简单的程序测试一下上方编写的代码。

 1 public class Client {
 2     
 3     public static void main(String[] args) {
 4         CashContext cashContext = null;
 5         
 6         Scanner scanner = new Scanner(System.in);
 7         System.out.print("请输入打折方式（1/2/3）：");
 8         int in = scanner.nextInt();
 9         String type = "";
10         
11         switch (in) {
12             case 1:
13                 cashContext = new CashContext(new CashNormal());
14                 type += "正常收费";
15                 break;
16                 
17             case 2:
18                 cashContext = new CashContext(new CashReturn(300, 100));
19                 type += "满300返100";
20                 break;
21                 
22             case 3:
23                 cashContext = new CashContext(new CashRebate(0.8));
24                 type += "打8折";
25                 break;
26     
27             default:
28                 System.out.println("请输入1/2/3");
29                 break;
30         }
31         
32         double totalPrices = 0;
33         
34         System.out.print("请输入单价：");
35         double price = scanner.nextDouble();
36         System.out.print("请输入数量：");
37         double num = scanner.nextDouble();
38         totalPrices = cashContext.getResult(price * num);
39         
40         System.out.println("单价：" + price + "，数量：" + num + "，类型：" + type + "，合计：" + totalPrices);
41         
42         scanner.close();
43     }
44 
45 }

　　正常收费结果如下：

　　返利收费结果如下：

　　打折收费结果如下：

责任链模式

废话不多说，先看看下面的代码。

publicinterface IPay {  
    void pay();  
}  

@Service
publicclass AliaPay implements IPay {  
     @Override
     public void pay() {  
        System.out.println("===发起支付宝支付===");  
     }  
}  

@Service
publicclass WeixinPay implements IPay {  
     @Override
     public void pay() {  
         System.out.println("===发起微信支付===");  
     }  
}  
  
@Service
publicclass JingDongPay implements IPay {  
     @Override
     public void pay() {  
        System.out.println("===发起京东支付===");  
     }  
}  

@Service
publicclass PayService {  
     @Autowired
     private AliaPay aliaPay;  
     @Autowired
     private WeixinPay weixinPay;  
     @Autowired
     private JingDongPay jingDongPay;  
    
   
     public void toPay(String code) {  
         if ("alia".equals(code)) {  
             aliaPay.pay();  
         } elseif ("weixin".equals(code)) {  
              weixinPay.pay();  
         } elseif ("jingdong".equals(code)) {  
              jingDongPay.pay();  
         } else {  
              System.out.println("找不到支付方式");  
         }  
     }  
}

PayService类的toPay方法主要是为了发起支付，根据不同的code，决定调用用不同的支付类（比如：aliaPay）的pay方法进行支付。

这段代码有什么问题呢？也许有些人就是这么干的。

试想一下，如果支付方式越来越多，比如：又加了百度支付、美团支付、银联支付等等，就需要改toPay方法的代码，增加新的else...if判断，判断多了就会导致逻辑越来越多？

很明显，这里违法了设计模式六大原则的：开闭原则和单一职责原则。

开闭原则：对扩展开放，对修改关闭。就是说增加新功能要尽量少改动已有代码。
单一职责原则：顾名思义，要求逻辑尽量单一，不要太复杂，便于复用。

这种方式在代码重构时用来消除if...else非常有效。

责任链模式：将请求的处理对象像一条长链一般组合起来，形成一条对象链。请求并不知道具体执行请求的对象是哪一个，这样就实现了请求与处理对象之间的解耦。

常用的filter、spring aop就是使用了责任链模式，这里我稍微改良了一下，具体代码如下：

publicabstractclass PayHandler {

    @Getter
    @Setter
    protected PayHandler next;

    public abstract void pay(String pay);

}

@Service
publicclass AliaPayHandler extends PayHandler {


    @Override
    public void pay(String code) {
        if ("alia".equals(code)) {
            System.out.println("===发起支付宝支付===");
        } else {
            getNext().pay(code);
        }
    }

}

@Service
publicclass WeixinPayHandler extends PayHandler {

    @Override
    public void pay(String code) {
        if ("weixin".equals(code)) {
            System.out.println("===发起微信支付===");
        } else {
            getNext().pay(code);
        }
    }
}

@Service
publicclass JingDongPayHandler extends PayHandler {


    @Override
    public void pay(String code) {
        if ("jingdong".equals(code)) {
            System.out.println("===发起京东支付===");
        } else {
            getNext().pay(code);
        }
    }
}

@Service
publicclass PayHandlerChain implements ApplicationContextAware, InitializingBean {

    private ApplicationContext applicationContext;
    private PayHandler header;


    public void handlePay(String code) {
        header.pay(code);
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        Map<String, PayHandler> beansOfTypeMap = applicationContext.getBeansOfType(PayHandler.class);
        if (beansOfTypeMap == null || beansOfTypeMap.size() == 0) {
            return;
        }
        List<PayHandler> handlers = beansOfTypeMap.values().stream().collect(Collectors.toList());
        for (int i = 0; i < handlers.size(); i++) {
            PayHandler payHandler = handlers.get(i);
            if (i != handlers.size() - 1) {
                payHandler.setNext(handlers.get(i + 1));
            }
        }
        header = handlers.get(0);
    }
}

这段代码的关键是每个PayHandler的子类，都定义了下一个需要执行的PayHandler子类，构成一个链式调用，通过PayHandlerChain把这种链式结构组装起来。

设计模式

单例模式

1. 单例模式简介

2. 单例模式的实现

饿汉式

懒汉式（线程不安全）

双重校验锁

静态内部类单例模式

工厂模式

一 工厂模式介绍

1.1 工厂模式的分类：

1.2 在开源框架中的使用

1.3 为什么要用工厂模式

二 简单工厂模式

2.1 介绍

2.2 适用场景

2.3 简单工厂模式角色分配：

2.4 简单工厂实例

2.5 使用反射机制改善简单工厂

三、工厂方法模式

3.1 介绍

3.2 适用场景

3.3 工厂方法模式角色分配：

3.4 工厂方法模式实例

四、 抽象工厂模式

4.1 介绍

4.2 适用场景

4.3 抽象工厂方法模式角色分配：

4.4 抽象工厂的工厂和工厂方法中的工厂有什么区别呢？

4.5 抽象工厂模式实例

策略模式

一、什么是策略模式

1. Context上下文

2. 策略角色

3. 具体策略角色

4. Client客户端

二、策略模式的应用

1. 何时使用

2. 方法

3. 优点

4. 缺点

5. 使用场景

6. 应用实例

7. 注意事项

三、策略模式的实现

1. 上下文类

2. 现金收费抽象类

3. 正常收费子类

4. 打折收费子类

5. 返利收费子类

6. Client客户端

责任链模式

一工厂模式介绍

二简单工厂模式

四、抽象工厂模式

　　1. 何时使用

　　2. 方法

　　3. 优点

　　4. 缺点

　　5. 使用场景

　　6. 应用实例

　　7. 注意事项

　　1. 上下文类

　　2. 现金收费抽象类

　　3. 正常收费子类

　　4. 打折收费子类

　　5. 返利收费子类

　　6. Client客户端