JAVA 设计模式篇

• 1、UML类图
• 2、设计原则
• • 2.1、开闭原则
  • 2.2、里氏代换原则
  • 2.3、依赖倒转原则
  • 2.4、接口隔离原则
  • 2.5、迪米特法则
  • 2.6、合成复用原则
• 3、设计模式
• • 3.1、单例模式
  • • 3.1.1、单例模式实现——饿汉式
    • • 3.1.1.1、静态变量实现
      • 3.1.1.2、静态方法实现
      • 3.1.1.3、枚举方式
    • 3.1.2、单例模式实现——懒汉式
    • • 3.1.2.1、线程不安全
      • 3.1.2.2、线程安全
      • 3.1.2.3、双重检查锁
      • 3.1.2.4、静态内部类方式
    • 3.1.3、破坏单例模式
    • • 3.1.3.1、通过序列化破坏
      • 3.1.3.2、通过反射破坏
      • 3.1.3.3、防止序列化影响单例模式
      • 3.1.3.4、防止反射影响单例模式
    • 3.1.4、JDK源码解析——Runtime类
  • 3.2、工厂方法模式
  • • 3.2.1、简单工厂模式
    • 3.2.2、工厂方法模式
  • 3.3、抽象工厂模式
  • • 3.3.1、模式扩展
  • 3.4、原型模式
  • • 3.4.1、简易实现原型模式
    • 3.4.2、使用原型模式进行克隆
    • 3.4.3、深克隆
  • 3.5、建造者模式
  • • 3.5.1、建造者模式案例
    • 3.5.2、使用场景
    • 3.5.3、模式扩展
    • 3.5.4、创建者模式对比
  • 3.6、代理模式
  • • 3.6.1、静态代理
    • 3.6.2、JDK动态代理
    • 3.6.3、CGLIB动态代理
    • 3.6.4、区别
  • 3.7、适配器模式
  • • 3.7.1、类适配器模式
    • 3.7.2、对象适配器模式
  • 3.8、装饰者模式
  • • 3.8.1、装饰者模式简单案例
    • 3.8.2、优点
  • 3.9、桥接模式
  • • 3.9.1、案例
  • 3.10、外观模式
  • • 3.10.1、案例
    • 3.10.2、优劣
  • 3.11、组合模式
  • • 3.11.1、案例
    • 3.11.2、组合模式分类
    • 3.11.3、优点
  • 3.12、享元模式
  • • 3.12.1、案例
    • 3.12.3、优劣
  • 3.13、模板方法模式
  • • 3.13.1、案例
    • 3.13.2、优劣
    • 3.13.3、JDK源码分析
  • 3.14、策略模式
  • • 3.14.1、案例
    • 3.14.2、优劣
    • 3.14.3、JDK源码分析
  • 3.15、命令模式
  • • 3.15.1、案例
    • 3.15.2、优劣
  • 3.16、责任链模式
  • • 3.16.1、案例
    • 3.16.2、优劣
  • 3.17、状态模式
  • • 3.17.1、案例
    • 3.17.2、优劣：
  • 3.18、发布订阅模式（观察者模式）
  • • 3.18.1、案例
    • 3.18.2、优劣
    • 3.18.3、源码分析
  • 3.19、中介者模式
  • • 3.19.1、案例
    • 3.19.2、优劣
  • 3.20、迭代器模式
  • • 3.20.1、案例
    • 3.20.2、优劣
  • 3.21、访问者模式
  • • 3.21.1、案例
    • 3.21.2、优劣
    • 3.12.3、分派
    • • 3.21.3.1、动态分派
      • 3.21.3.2、静态分派
      • 3.21.3.3、双分派
  • 3.22、备忘录模式
  • • 3.22.1、结构
    • 3.22.2、案例
    • 3.22.3、白箱备忘录模式
    • 3.22.4、黑箱备忘录模式
    • 3.22.5、优劣
  • 3.23、解释器模式
  • • 3.23.1、案例
    • 3.23.2、优劣

1、UML类图

类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性的信息。类图是面向对象建模的主要组成部分。

类图就不做多概述了，在大学编程基础都会对此有所了解，而绘制类图只是为了更加清晰的表示类与类直接的关系

2、设计原则

Gitee源码地址：https://gitee.com/modify_lzq/service-lzq-design.git

2.1、开闭原则

在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。想要达到这样的效果，我们需要使用接口和抽象类。
git代码见 service-lzq-design\src\main\java\com\lzq\principle\openandclose

2.2、里氏代换原则

任何基类可以出现的地方，子类一定可以出现。通俗理解：子类可以扩展父类的功能，但不能改变父类原有的功能。换句话说，子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
git代码见 service-lzq-design\src\main\java\com\lzq\principle\richter

2.3、依赖倒转原则

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
git代码见 service-lzq-design\src\main\java\com\lzq\principle\dependency

2.4、接口隔离原则

客户端不应该被迫依赖于它不使用的方法；一个类对另一个类的依赖应该建立在最小的接口上。
git代码见 service-lzq-design\src\main\java\com\lzq\principle\isolation

2.5、迪米特法则

如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
git代码见 service-lzq-design\src\main\java\com\lzq\principle\dimit

2.6、合成复用原则

尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

3、设计模式

3.1、单例模式

这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

3.1.1、单例模式实现——饿汉式

类加载就会导致该单实例对象被创建

3.1.1.1、静态变量实现

该方式在成员位置声明HungryStyleVar类型的静态变量，并创建HungryStyleVar类的对象hungryStyleVar。hungryStyleVar对象是随着类的加载而创建的。

public class HungryStyleVar {/*** 静态成员变量*/private static HungryStyleVar hungryStyleVar = new HungryStyleVar();private HungryStyleVar() {}public static HungryStyleVar getInstance() {return hungryStyleVar;}
}

3.1.1.2、静态方法实现

该方式在成员位置声明HungryStyleFunc类型的静态变量，而对象的创建是在静态代码块中，也是对着类的加载而创建。

public class HungryStyleFunc {/*** 静态成员变量*/private static HungryStyleFunc hungryStyleFunc;static {hungryStyleFunc = new HungryStyleFunc();}private HungryStyleFunc() {}public static HungryStyleFunc getInstance() {return hungryStyleFunc;}
}

3.1.1.3、枚举方式

枚举类实现单例模式是极力推荐的单例实现模式，因为枚举类型是线程安全的，并且只会装载一次

public enum LazyEnum {INSTANCE
}class LazyEnumTest {public static void main(String[] args) {LazyEnum instance = LazyEnum.INSTANCE;LazyEnum instance1 = LazyEnum.INSTANCE;System.out.println(instance == instance1);}
}

3.1.2、单例模式实现——懒汉式

3.1.2.1、线程不安全

从上面代码我们可以看出该方式在成员位置声明LazyStyleVar类型的静态变量，并没有进行对象的赋值操作，那么什么时候赋值的呢？当调用getInstance()方法获取LazyStyleVar类的对象的时候才创建Singleton类的对象，这样就实现了懒加载的效果。但是，如果是多线程环境，会出现线程安全问题。

public class LazyStyleVar {private LazyStyleVar() {}private static LazyStyleVar lazyStyleVar;public static LazyStyleVar getInstance() {if (lazyStyleVar == null) {lazyStyleVar = new LazyStyleVar();}return lazyStyleVar;}
}

3.1.2.2、线程安全

看完上述线程不安全的代码，可以发现当多线程进行执行时，getInstance方法进来之后两个lazyStyleVar 同时实例化，这样这两个线程得到的LazyStyleVar对象就不是同一个对象了，解决的方法也很简单，我们可以直接利用JVM锁，直接给方法加上synchronized关键字，用来表示同步。

3.1.2.3、双重检查锁

对于 getInstance() 方法来说，绝大部分的操作都是读操作，读操作是线程安全的，所以我们没必让每个线程必须持有锁才能调用该方法，我们需要调整加锁的时机。双重检查锁模式是一种非常好的单例实现模式，解决了单例、性能、线程安全问题，上面的双重检测锁模式看上去完美无缺，其实是存在问题，在多线程的情况下，可能会出现空指针问题，出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作。要解决双重检查锁模式带来空指针异常的问题，只需要使用 volatile 关键字, volatile 关键字可以保证可见性和有序性。

public class LazyStyleLock {private LazyStyleLock() {}private static volatile LazyStyleLock lazyStyleLock;public static synchronized LazyStyleLock getInstance() {if (lazyStyleLock == null) {synchronized (LazyStyleLock.class) {if (lazyStyleLock == null) {lazyStyleLock = new LazyStyleLock();}}}return lazyStyleLock;}
}

3.1.2.4、静态内部类方式

静态内部类单例模式中实例由内部类创建，由于 JVM 在加载外部类的过程中, 是不会加载静态内部类的, 只有内部类的属性/方法被调用时才会被加载, 并初始化其静态属性。静态属性由于被 static 修饰，保证只被实例化一次，并且严格保证实例化顺序。

public class LazyStyleClass {private LazyStyleClass() {}private static class LazyStyleClassWithin {private static final LazyStyleClass lazyStyleClass = new LazyStyleClass();}public static LazyStyleClass getInstance() {return LazyStyleClassWithin.lazyStyleClass;}
}

3.1.3、破坏单例模式

3.1.3.1、通过序列化破坏

public class Singleton implements Serializable {private static Singleton singleton = new Singleton();public static Singleton getInstance() {return singleton;}
}class Test {public static void main(String[] args) throws Exception {Test.readObjectFromFile();Test.readObjectFromFile();}private static Singleton readObjectFromFile() throws Exception {ObjectInputStream ois = new ObjectInputStream(new FileInputStream("D:\\data\\a.txt"));Singleton instance = (Singleton) ois.readObject();System.out.println(instance);return instance;}public static void writeObject2File() throws Exception {Singleton instance = Singleton.getInstance();ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("D:\\data\\a.txt"));oos.writeObject(instance);}
}

3.1.3.2、通过反射破坏

public class Singleton {private static Singleton singleton = new Singleton();public static Singleton getInstance() {return singleton;}
}class ReflexTest {public static void main(String[] args) throws Exception {Class singletonClass = Singleton.class;Constructor declaredConstructors = singletonClass.getDeclaredConstructor();declaredConstructors.setAccessible(true);Singleton instance = (Singleton) declaredConstructors.newInstance();Singleton instance1 = (Singleton) declaredConstructors.newInstance();System.out.println(instance == instance1);}
}

3.1.3.3、防止序列化影响单例模式

在Singleton类中添加readResolve()方法，在反序列化时被反射调用，如果定义了这个方法，就返回这个方法的值，如果没有定义，则返回新new出来的对象。

public class Singleton implements Serializable {private static Singleton singleton = new Singleton();private static class SingletonHolder {private static final Singleton INSTANCE = new Singleton();}public static Singleton getInstance() {return SingletonHolder.INSTANCE;}public Object readResolve() {return SingletonHolder.INSTANCE;}
}class Test {public static void main(String[] args) throws Exception {Test.writeObject2File();Test.readObjectFromFile();Test.readObjectFromFile();}private static Singleton readObjectFromFile() throws Exception {ObjectInputStream ois = new ObjectInputStream(new FileInputStream("D:\\data\\a.txt"));Singleton instance = (Singleton) ois.readObject();System.out.println(instance);return instance;}public static void writeObject2File() throws Exception {Singleton instance = Singleton.getInstance();ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("D:\\data\\a.txt"));oos.writeObject(instance);}
}

源码分析：为什么加上了readResolve方法就能保证单例模式不会被破坏

// 在代码当中我们读取对象的时候是通过ObjectInputStream对象的readObject进行读取的，我们直接进去看一下这个方法是怎么实现的
Singleton instance = (Singleton) ois.readObject();
// 进入之后他里面调用了该方法进行返回了一个object，我们看一下这个readObject0方法
Object obj = readObject0(false);
// 进去之后会有一个switch case进行分支判断，这里我们直接找对应的Object即可，直接进去readOrdinaryObject方法
case TC_OBJECT:return checkResolve(readOrdinaryObject(unshared));
// 进入之后只需要看哪里对该readResolve方法进行判断即可。
if (obj != null && handles.lookupException(passHandle) == null && desc.hasReadResolveMethod())
// 而正是通过该代码进行赋值将obj整给了rep。调用表示的可序列化类的readResolve方法并返回结果。如果此类描述符未与类关联，或者该类不可序列化或未定义readResolve，则引发UnsupportedOperationException。
Object rep = desc.invokeReadResolve(obj);
// 里面方法的实现大概看一下就知道其含义了。如果表示的类是可序列化或可外部化的，并且定义了一致的readResolve方法，则返回true。否则，返回false。
boolean hasReadResolveMethod() {requireInitialized();return (readResolveMethod != null);
}
// 而readOrdinaryObject方法最后表明的含义是如果单例对象之前已经被实例化过，那么rep就会指向之前实例化的单例对象。如果我们之前没有实例化单例对象，则rep会指向null。
// rep与obj进行比较，由于obj是反射获取的对象，当然与rep不等，于是将rep的值instance赋值给obj，将obj返回，返回对象instance也就保证了单例。

3.1.3.4、防止反射影响单例模式

这个是直接在构造方法当中对是否创建了对象进行判断限制

public class Singleton {private Singleton() {if (!flag) {throw new RuntimeException("对象已创建");} else {flag = true;}}private static boolean flag = false;private static class SingletonWithin {private static final Singleton singleton = new Singleton();}
}

3.1.4、JDK源码解析——Runtime类

直接进入到这个RunTime类可以看到这就是前面所说的单例模式的-饿汉式实现的单例。private修饰的构造方法以及提供了一个获取对应实例的一个getRuntime方法

3.2、工厂方法模式

当我们使用一下代码来进行实现功能的时候，我们会发现一些问题。

在java中，万物皆对象，这些对象都需要创建，如果创建的时候直接new该对象，就会对该对象耦合严重，假如我们要更换对象，所有new对象的地方都需要修改一遍，这显然违背了软件设计的开闭原则。如果我们使用工厂来生产对象，我们就只和工厂打交道就可以了，彻底和对象解耦，如果要更换对象，直接在工厂里更换该对象即可，达到了与对象解耦的目的；所以说，工厂模式最大的优点就是：解耦。

3.2.1、简单工厂模式

简单工厂模式就是将创建咖啡的功能给单独抽离出来，用一个工厂进行管理，这样做的优点在于封装了创建对象的过程，可以通过参数直接获取对象。把对象的创建和业务逻辑层分开，这样以后就避免了修改客户代码，如果要实现新产品直接修改工厂类，而不需要在原代码中修改，这样就降低了客户代码修改的可能性，更加容易扩展。但是在后续增加新的类型还是要修改工厂类，还是违背了“开闭原则”

当然我们可以直接给createCoffee方法加上static静态，就可以直接通过类调用方法，不需要创建工厂类了

3.2.2、工厂方法模式

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

这样做的好处在于我们只需要知道具体工厂的名称就可得到所要的产品，并不需要关注其是如何创建的，而且在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则；

但是每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度。

3.3、抽象工厂模式

抽象工厂是一种为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。

3.3.1、模式扩展

可以通过工厂模式+配置文件的方式解除工厂对象和产品对象的耦合。在工厂类中加载配置文件中的全类名，并创建对象进行存储，客户端如果需要对象，直接进行获取即可。

这里我们定义一个配置文件，将对应的全类名用一个变量进行接收 【bean.properties】

usa=com.lzq.model.factory.abs.UsaCoffee
latte=com.lzq.model.factory.abs.LatteCoffee

静态成员变量用来存储创建的对象（键存储的是名称，值存储的是对应的对象），而读取配置文件以及创建对象写在静态代码块中，目的就是只需要执行一次。

public class CoffeeStaticFactory {private static Map map = new HashMap();static {Properties properties = new Properties();InputStream resourceAsStream = CoffeeStaticFactory.class.getClassLoader().getResourceAsStream("bean.properties");try {properties.load(resourceAsStream);Set