设计模式Design patterns

前言：

（1）、该文章的英文版本地址：https://copyfuture.com/blogs-details/20210109223347268d，

（2）、中文版本地址：https://blog.csdn.net/qq_42986622/article/details/120743239

（3）、设计模式还可以参考菜鸟教程：https://www.runoob.com/design-pattern/composite-pattern.html

　　设计模式是对大家实际工作中写的各种代码进行高层次抽象的总结，其中最出名的当属 Gang of Four (GoF) 的分类了，他们将设计模式分类为 23 种经典的模式，根据用途我们又可以分为三大类，分别为创建型模式、结构型模式和行为型模式。

有一些重要的设计原则在开篇和大家分享下，这些原则将贯通全文：

1、面向接口编程，而不是面向实现。这个很重要，也是优雅的、可扩展的代码的第一步，这就不需要多说了吧。

2、职责单一原则。每个类都应该只有一个单一的功能，并且该功能应该由这个类完全封装起来。

3、对修改关闭，对扩展开放。对修改关闭是说，我们辛辛苦苦加班写出来的代码，该实现的功能和该修复的 bug 都完成了，别人可不能说改就改；对扩展开放就比较好理解了，也就是说在我们写好的代码基础上，很容易实现扩展。

创建型模式比较简单，但是会比较没有意思，结构型和行为型比较有意思。

一、创建型模式Create pattern

创建型模式的作用就是创建对象，说到创建一个对象，最熟悉的就是 new 一个对象，然后 set 相关属性。但是，在很多场景下，我们需要给客户端提供更加友好的创建对象的方式，尤其是那种我们定义了类，但是需要提供给其他开发者用的时候。

1、简单工厂模式simple Factory model

和名字一样简单，非常简单，直接上代码吧：

Food类

public class Food {
    public void addSpicy(String str1) {
        System.out.println("加" + str1 + "辣");
    }
    public void addCondiment(String str2) {
        System.out.println("加" + str2);
    }
}

HuangMenChicken类

public class HuangMenChicken extends Food{
}

LanZhouNoodle类

public class LanZhouNoodle extends Food{
}

FoodFactory类

public class FoodFactory {
    public static Food makeFood(String name) {
        if (name.equals("noodle")) {
            Food noodle = new LanZhouNoodle();
            noodle.addSpicy("more");
            return noodle;
        } else if (name.equals("chicken")) {
            Food chicken = new HuangMenChicken();
            chicken.addCondiment("potato");
            return chicken;
        } else {
            return null;
        }
    }
}

简单地说，简单工厂模式通常就是这样，一个工厂类 XxxFactory，里面有一个静态方法，根据我们不同的参数，返回不同的派生自同一个父类（或实现同一接口）的实例对象。

我们强调职责单一 原则，一个类只提供一种功能，FoodFactory 的功能就是只要负责生产各种 Food。

客户端调用如下：

public class Client {
    public static void main(String[] args) {
        Food noodle = FoodFactory.makeFood("noodle");
        Food chicken = FoodFactory.makeFood("chicken");
    }
}

2、工厂模式Factory mode

简单工厂模式很简单，如果它能满足我们的需要，我觉得就不要折腾了。之所以需要引入工厂模式，是因为我们往往需要使用两个或两个以上的工厂。

Food父类

public class Food {
}

ChineseFoodA

public class ChineseFoodA extends Food{
}

ChineseFoodB

public class ChineseFoodB extends Food{
}

ChineseFoodFactory

public class ChineseFoodFactory implements FoodFactory {
    @Override
    public Food makeFood(String name) {
        if (name.equals("A")) {
            return new ChineseFoodA();
        } else if (name.equals("B")) {
            return new ChineseFoodB();
        } else {
            return null;
        }
    }
}

AmericanFoodA

public class AmericanFoodA extends Food{
}

AmericanFoodB

public class ChineseFoodB extends Food{
}

AmericanFoodFactory

public class AmericanFoodFactory implements FoodFactory{
    @Override
    public Food makeFood(String name) {
        if (name.equals("A")) {
            return new AmericanFoodA();
        } else if (name.equals("B")) {
            return new AmericanFoodB();
        } else {
            return null;
        }
    }
}

FoodFactory接口:

public interface FoodFactory {
    Food makeFood(String name);
}

客户端调用：

public class Client {
    public static void main(String[] args) {
        // 先选择一个具体的工厂
        FoodFactory factory = new ChineseFoodFactory();
        // 由第一步的工厂产生具体的对象，不同的工厂造出不一样的对象
        Food food = factory.makeFood("A");
        FoodFactory factory1 = new AmericanFoodFactory();
        Food food1 = factory1.makeFood("A");
    }
}

虽然都是调用 makeFood("A") 制作 A 类食物，但是，不同的工厂生产出来的完全不一样。

第一步，我们需要选取合适的工厂，然后第二步基本上和简单工厂一样。

核心在于，我们需要在第一步选好我们需要的工厂 。比如，我们有 LogFactory 接口，实现类有 FileLogFactory 和 KafkaLogFactory，分别对应将日志写入文件和写入 Kafka 中，显然，我们客户端第一步就需要决定到底要实例化 FileLogFactory 还是 KafkaLogFactory，这将决定之后的所有的操作。

虽然简单，不过我也把所有的构件都画到一张图上，这样读者看着比较清晰：

3、抽象工厂模式Abstract factory pattern

当涉及到产品族 的时候，就需要引入抽象工厂模式了。

一个经典的例子是造一台电脑。我们先不引入抽象工厂模式，看看怎么实现。

因为电脑是由许多的构件组成的，我们将 CPU 和主板进行抽象，然后 CPU 由 CPUFactory 生产，主板由 MainBoardFactory 生产，然后，我们再将 CPU 和主板搭配起来组合在一起，如下图：

CPU父类

public class CPU {
}

IntelCPU子类

public class IntelCPU extends CPU{
}

AmdCPU子类

public class AmdCPU extends CPU{
}

CPUFactory接口

public interface CPUFactory {
    CPU makeCPU();
}

IntelCPUFactory实现类

public class IntelCPUFactory implements CPUFactory{
    @Override
    public CPU makeCPU() {
        return new IntelCPU();
    }
}

AmdCPUFactory实现类

public class AmdCPUFactory implements CPUFactory{
    @Override
    public CPU makeCPU() {
        return new AmdCPU();
    }
}

MainBoard父类

public class MainBoard {
}

IntelMainBoard子类

public class IntelMainBoard extends MainBoard{
}

AmdMainBoard子类

public class AmdMainBoard extends MainBoard{
}

MainBoardFactory接口

public interface MainBoardFactory {
    MainBoard makeBoard();
}

IntelMainBoardFactory实现类

public class IntelMainBoardFactory implements MainBoardFactory{
    @Override
    public MainBoard makeBoard() {
        return new IntelMainBoard();
    }
}

AmdMainBoardFatory实现类

public class AmdMainBoardFactory implements MainBoardFactory{
    @Override
    public MainBoard makeBoard() {
        return new AmdMainBoard();
    }
}

Computer实体类

public class Computer {
    private CPU cpu;
    private MainBoard mainBoard;
    public Computer(CPU cpu, MainBoard mainBoard) {
        this.cpu = cpu;
        this.mainBoard = mainBoard;
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        // 得到 Intel 的 CPU
        CPUFactory intelCPUFactory = new IntelCPUFactory();
        CPU cpu = intelCPUFactory.makeCPU();
        // 得到 AMD 的主板
        MainBoardFactory mainBoardFactory = new AmdMainBoardFactory();
        MainBoard mainBoard = mainBoardFactory.makeBoard();
        // 组装 CPU 和主板
        Computer computer = new Computer(cpu, mainBoard);
    }
}

单独看 CPU 工厂和主板工厂，它们分别是前面我们说的工厂模式 。这种方式也容易扩展，因为要给电脑加硬盘的话，只需要加一个 HardDiskFactory 和相应的实现即可，不需要修改现有的工厂。

但是，这种方式有一个问题，那就是如果 Intel 家产的 CPU 和 AMD 产的主板不能兼容使用 ，那么这代码就容易出错，因为客户端并不知道它们不兼容，也就会错误地出现随意组合，不能把IntelCPU和AmdMainBoard随意组合来生产电脑。

下面就是我们要说的产品族 的概念，它代表了组成某个产品的一系列附件的集合：

当涉及到这种产品族的问题的时候，就需要抽象工厂模式来支持了。我们不再定义 CPU 工厂、主板工厂、硬盘工厂、显示屏工厂等等，我们直接定义电脑工厂，每个电脑工厂负责生产所有的设备，这样能保证肯定不存在兼容问题。

ComputerFactory

public interface ComputerFactory {
    CPU makeCPU();
    MainBoard makeMainBoard();
}

IntelFactory

public class IntelFactory implements ComputerFactory {
    @Override
    public CPU makeCPU() {
        return new IntelCPU();
    }

    @Override
    public MainBoard makeMainBoard() {
        return new IntelMainBoard();
    }
}

AmdFactory

public class AmdFactory implements ComputerFactory{
    @Override
    public CPU makeCPU() {
        return new AmdCPU();
    }
    @Override
    public MainBoard makeMainBoard() {
        return new MainBoard();
    }
}

客户端调用：

public class Client {
    public static void main(String[] args) {// 第一步就要选定一个“大厂”
        ComputerFactory cf = new AmdFactory();
        // 从这个大厂造 CPU
        CPU cpu = cf.makeCPU();
        // 从这个大厂造主板
        MainBoard board = cf.makeMainBoard();
        // 将同一个厂子出来的 CPU、主板组装在一起
        Computer result = new Computer(cpu, board);
    }
}

这个时候，对于客户端来说，不再需要单独挑选 CPU厂商、主板厂商、硬盘厂商等，直接选择一家品牌工厂，品牌工厂会负责生产所有的东西，而且能保证肯定是兼容可用的。

当然，抽象工厂的问题也是显而易见的，比如我们要加个显示器，就需要修改所有的工厂，给所有的工厂都加上制造显示器的方法。这有点违反了对修改关闭，对扩展开放（Turn off for changes , Open to expansion） 这个设计原则。

4、单例模式The singleton pattern

单例模式用得最多，错得最多。

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

饿汉模式（The hungry man model）最简单：

public class Singleton {
    // 首先，让构造函数为private，这样该类就不会实例化，将 new Singleton() 堵死
    private Singleton() {};
    // 创建私有静态实例，意味着这个类第一次使用的时候就会进行创建
    private static Singleton instance = new Singleton();
    // 获取唯一可用的对象
    public static Singleton getInstance() {
        return instance;
    }
    // 瞎写一个静态方法。这里想说的是，如果我们只是要调用 Singleton.getDate(...)，
    // 本来是不想要生成 Singleton 实例的，不过没办法，已经生成了
    public static Date getDate(String mode) {return new Date();}
    public void showMessage(){
        System.out.println("Hello World!");
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        //不合法的构造函数
        //编译时错误：构造函数 SingleObject() 是不可见的
        // Singleton singleton = new Singleton();
        //获取唯一可用的对象
        Singleton singleton = Singleton.getInstance();
        singleton.showMessage();
    }
}

结果：Hello World!

很多人都能说出饿汉模式的缺点，可是我觉得生产过程中，很少碰到这种情况：你定义了一个单例的类，不需要其实例，可是你却把一个或几个你会用到的静态方法塞到这个类中。

饱汉模式（Full Han mode）最容易出错：

采用双锁机制，安全且在多线程情况下能保持高性能

public class Singleton {
    // 首先，也是先堵死 new Singleton() 这条路
    private Singleton() {}
    // 和饿汉模式相比，这边不需要先实例化出来，注意这里的 volatile，它是必须的
    private static volatile Singleton instance = null;

    public static Singleton getInstance() {
        if (instance == null) { // 避免进入所，减少性能开销
            // 加锁，
            synchronized (Singleton.class) {
                // 这一次判断也是必须的，不然会有并发问题，避免生成多个实例对象
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

双重检查，指的是两次检查 instance 是否为 null。一次是在同步代码块外，一次是在同步代码块内。为什么在同步代码块内还要再检验一次？

第一个if减少性能开销，第二个if避免生成多个对象实例。

　　现有三个线程A，B，C，假设线程A和线程B同时调用getInstance（）时，判断第一层if判断都为空，这时线程A先拿到锁，线程B在代码块外层等待。线程A进行第二层if判断，条件成立后new了一个新对象，创建完成，释放锁，线程B拿到锁，进行第二层if判断，singleton不为空，直接返回singleton释放锁，避免生成多个对象实例。线程线C调用getSingleton时第一层判断不成立，直接拿到singleton对象返回，避免进入锁，减少性能开销。

volatile 在这里是需要的，volatile禁止指令重排序，希望能引起读者的关注。

为什么要用volatile关键字？

singleton = new Singleton();这行代码并不是一个原子指令，可能会在JVM中进行指令重排；

new 实例背后的指令，我们通过使用 javap -c指令，查看字节码如下：

我们要找到class文件，先找到target目录，由于不是写在test目录中，故找到classes，target\classes\com\zwh\singleton\fullman，在该目录中打开cmd，输入如下命令：

javap -v Singleton.class > Singleton.txt

打开Singleton.txt文件，部分内容如下：

public static com.zwh.singleton.fullMan.Singleton getInstance();
    descriptor: ()Lcom/zwh/singleton/fullMan/Singleton; // 方法描述，返回值为Singleton
    flags: ACC_PUBLIC, ACC_STATIC    // 方法修饰符，public、static的
    Code:  // 代码
      stack=2, locals=2, args_size=0  // stack=2 表示操作栈的大小为2，locals=2 本地变量表大小  args_size=0 参数的个数为0
         0: getstatic     #2                  // Field instance:Lcom/zwh/singleton/fullMan/Singleton;
         3: ifnonnull     37
         6: ldc           #3                  // class com/zwh/singleton/fullMan/Singleton
         8: dup
         9: astore_0
        10: monitorenter
        11: getstatic     #2                  // Field instance:Lcom/zwh/singleton/fullMan/Singleton;
        14: ifnonnull     27
        17: new           #3                  // class com/zwh/singleton/fullMan/Singleton
        20: dup
        21: invokespecial #4                  // Method "<init>":()V
        24: putstatic     #2                  // Field instance:Lcom/zwh/singleton/fullMan/Singleton;
        27: aload_0
        28: monitorexit
        29: goto          37
        32: astore_1
        33: aload_0
        34: monitorexit
        35: aload_1
        36: athrow
        37: getstatic     #2                  // Field instance:Lcom/zwh/singleton/fullMan/Singleton;
        40: areturn

synchronized的同步操作主要是monitorenter和monitorexit这两个jvm指令实现的。monitorexit为什么会有两个？

第一个monitorexit指令是同步代码块正常释放锁的一个标志；如果同步代码块中出现Exception或者Error，则会调用第二个monitorexit指令来保证释放锁。

invokespecial：调用一些需要特殊处理的实例方法，包括实例初始化方法（构造器）、私有方法、父类方法

提取其中部分进行分析：

// 分配内存
17: new           #3                  // class com/zwh/singleton/fullMan/Singleton             
// 复制栈顶地址，并再将其压入栈顶
20: dup
// 调用构造器方法，初始化 Singleton对象
21: invokespecial #4                  // Method "<init>":()V
// 存入本地变量表中下标为1的位置
32: astore_1

从字节码可以看到创建一个对象实例，可以分为三步：

(1)、分配对象内存(给singleton分配内存)。

(2)、调用构造器方法，执行初始化（调用 Singleton 的构造函数来初始化成员变量）。

(3)、将对象引用赋值给变量(执行完这步 singleton 就为非 null 了)。

　　在 JVM 的即时编译器中存在指令重排序的优化。指令重排并不影响单线程内的执行结果，但是在多线程内可能会影响结果。也就是说上面的2和3的顺序是不能保证的，但是并不会重排序 1 的顺序，因为 2,3 指令需要依托 1 指令执行结果。最终的执行顺序可能是 1-2-3 也可能是 1-3-2。

1-3-2的情况

　　上面多线程执行的流程中，如果线程A获取到锁进入创建对象实例，这个时候发生了指令重排序。当线程A 执行到 t3 时刻(singleton已经非null了，但是却没有初始化)，此时线程 B 抢占了，由于此时singleton已经不为 Null，会直接返回 singleton对象，然后使用singleton对象，然而该对象还未初始化，就会报错。我们只需将 singleton 变量声明成 volatile 就可以禁止指令重排，避免这种现象发生。

很多人不知道怎么写，直接就在 getInstance() 方法签名上加上 synchronized，这就不多说了，性能太差。

嵌套类(Nested classes)最经典，以后大家就用它吧：

public class Singleton {
    private Singleton() {}
    // 主要是使用了 嵌套类可以访问外部类的静态属性和静态方法 的特性
    private static class Holder {
        private static Singleton instance = new Singleton();
    }
    public static Singleton getInstance() {
        return Holder.instance;
    }
}

注意，很多人都会把这个嵌套类 说成是静态内部类 ，严格地说，内部类和嵌套类是不一样的，它们能访问的外部类权限也是不一样的。

最后，我们说一下枚举，枚举很特殊，它在类加载的时候会初始化里面的所有的实例，而且 JVM 保证了它们不会再被实例化，所以它天生就是单例的。

虽然我们平时很少看到用枚举来实现单例，但是在 RxJava 的源码中，有很多地方都用了枚举来实现单例。

5、建造者模式Builder pattern

经常碰见的 XxxBuilder 的类，通常都是建造者模式的产物。建造者模式其实有很多的变种，但是对于客户端来说，我们的使用通常都是一个模式的：

Food food = new FoodBuilder().a().b().c().build();
Food food = Food.builder().a().b().c().build();

套路就是先 new 一个 Builder，然后可以链式地调用一堆方法，最后再调用一次 build() 方法，我们需要的对象就有了。

来一个中规中矩的建造者模式：

class User {
    // 下面是“一堆”的属性
    private String name;
    private String password;
    private String nickName;
    private int age;

    // 构造方法私有化，不然客户端就会直接调用构造方法了
    private User(String name, String password, String nickName, int age) {
        this.name = name;
        this.password = password;
        this.nickName = nickName;
        this.age = age;
    }
    // 静态方法，用于生成一个 Builder，这个不一定要有，不过写这个方法是一个很好的习惯，
    // 有些代码要求别人写 new User.UserBuilder().a()...build() 看上去就没那么好
    public static UserBuilder builder() {
        return new UserBuilder();
    }

    public static class UserBuilder {
        // 下面是和 User 一模一样的一堆属性
        private String  name;
        private String password;
        private String nickName;
        private int age;

        private UserBuilder() {
        }

        // 链式调用设置各个属性值，返回 this，即 UserBuilder
        public UserBuilder name(String name) {
            this.name = name;
            return this;
        }

        public UserBuilder password(String password) {
            this.password = password;
            return this;
        }

        public UserBuilder nickName(String nickName) {
            this.nickName = nickName;
            return this;
        }

        public UserBuilder age(int age) {
            this.age = age;
            return this;
        }

        // build() 方法负责将 UserBuilder 中设置好的属性“复制”到 User 中。
        // 当然，可以在 “复制” 之前做点检验
        public User build() {
            if (name == null || password == null) {
                throw new RuntimeException("用户名和密码必填");
            }
            if (age <= 0 || age >= 150) {
                throw new RuntimeException("年龄不合法");
            }
            // 还可以做赋予”默认值“的功能
            if (nickName == null) {
                nickName = name;
            }
            return new User(name, password, nickName, age);
        }
    }
}

核心是：先把所有的属性都设置给 Builder，然后 build() 方法的时候，将这些属性复制给实际产生的对象。

客户端的调用

public class Client {
    public static void main(String[] args) {
        User user = User.builder().name("foo").password("pAss12345").age(25).build();
    }
}

说实话，建造者模式的链式写法很吸引人，但是，多写了很多“无用”的 builder 的代码，感觉这个模式没什么用。不过，当属性很多，而且有些必填，有些选填的时候，这个模式会使代码清晰很多。我们可以在 Builder 的构造方法 中强制让调用者提供必填字段，还有，在 build() 方法中校验各个参数比在 User 的构造方法中校验，代码要优雅一些。

题外话，强烈建议读者使用 lombok，用了 lombok 以后，上面的一大堆代码会变成如下这样:

@Builder
@ToString
public class User {
    private String  name;
    private String password;
    private String nickName;
    private int age;
}

怎么样，省下来的时间是不是又可以干点别的了。

客户端的调用

public class Client {
    public static void main(String[] args) {
        User user = User.builder().name("zhangsan").password("pAss12345").age(26).build();
        System.out.println(user);
    }
}

结果：

User(name=zhangsan, password=pAss12345, nickName=null, age=26)

当然，如果你只是想要链式写法，不想要建造者模式，有个很简单的办法，User 的 getter 方法不变，所有的 setter 方法都让其 return this 就可以了，然后就可以像下面这样调用：

@Getter
@ToString
public class Student {
    private String  name;
    private String password;
    private String nickName;
    private int age;

    public Student setName(String name) {
        this.name = name;
        return this;
    }
    public Student setPassword(String password) {
        this.password = password;
        return this;
    }
    public Student setNickName(String nickName) {
        this.nickName = nickName;
        return this;
    }
    public Student setAge(int age) {
        this.age = age;
        return this;
    }
}

客户端调用

public class Client1 {
    public static void main(String[] args) {
        Student student = new Student().setName("lisi").setPassword("123456").setAge(30);
        System.out.println(student);
    }
}

结果：

Student(name=lisi, password=123456, nickName=null, age=30)

很多人是这么用的，但是笔者觉得其实这种写法非常地不优雅，不是很推荐使用。

实际开发中，如果想要链式写法，可以使用@Accessors(chain = true)注解。

6、原型模式Archetypal model

这是我要说的创建型模式的最后一个设计模式了。

原型模式很简单：有一个原型实例，基于这个原型实例产生新的实例，也就是“克隆”了。

Object 类中有一个 clone() 方法，它用于生成一个新的对象，当然，如果我们要调用这个方法，java 要求我们的类必须先实现 Cloneable 接口 ，此接口没有定义任何方法，但是不这么做的话，在 clone() 的时候，会抛出 CloneNotSupportedException 异常。

protected native Object clone() throws CloneNotSupportedException;

java 的克隆是浅克隆，碰到对象引用的时候，克隆出来的对象和原对象中的引用将指向同一个对象。通常实现深克隆的方法是将对象进行序列化，然后再进行反序列化。

原型模式了解到这里我觉得就够了，各种变着法子说这种代码或那种代码是原型模式，没什么意义。

创建一个实现了 Cloneable 接口的抽象类

public abstract class Shape implements Cloneable {
    private String id;
    protected String type;

    abstract void draw();

    public String getType(){
        return type;
    }
    public String getId() {
        return id;
    }
    public void setId(String id) {
        this.id = id;
    }
    public Object clone() {
        Object clone = null;
        try {
            clone = super.clone();
        } catch (CloneNotSupportedException e) {
            e.printStackTrace();
        }
        return clone;
    }
}

创建扩展了上面抽象类的实体类。

Rectangle

public class Rectangle extends Shape{
    public Rectangle(){
        type = "Rectangle";
    }
    @Override
    void draw() {
        System.out.println("Inside Rectangle::draw() method.");
    }
}

Square

public class Square extends Shape{
    public Square(){
        type = "Square";
    }
    @Override
    void draw() {
        System.out.println("Inside Square::draw() method.");
    }
}

Circle

public class Circle extends Shape{
    public Circle(){
        type = "Circle";
    }
    @Override
    void draw() {
        System.out.println("Inside Circle::draw() method.");
    }
}

创建一个类，从数据库获取实体类，并把它们存储在一个 Hashtable 中。

import java.util.Hashtable;

public class ShapeCache {

    private static Hashtable<String, Shape> shapeMap
            = new Hashtable<String, Shape>();

    public static Shape getShape(String shapeId) {
        Shape cachedShape = shapeMap.get(shapeId);
        return (Shape) cachedShape.clone();
    }

    // 对每种形状都运行数据库查询，并创建该形状
    // shapeMap.put(shapeKey, shape);
    // 例如，我们要添加三种形状
    public static void loadCache() {
        Circle circle = new Circle();
        circle.setId("1");
        shapeMap.put(circle.getId(),circle);

        Square square = new Square();
        square.setId("2");
        shapeMap.put(square.getId(),square);

        Rectangle rectangle = new Rectangle();
        rectangle.setId("3");
        shapeMap.put(rectangle.getId(),rectangle);
    }
}

使用 ShapeCache 类来获取存储在 Hashtable 中的形状的克隆

public class PrototypePatternDemo {
    public static void main(String[] args) {
        ShapeCache.loadCache();

        Shape clonedShape = (Shape) ShapeCache.getShape("1");
        System.out.println("Shape : " + clonedShape.getType());

        Shape clonedShape2 = (Shape) ShapeCache.getShape("2");
        System.out.println("Shape : " + clonedShape2.getType());

        Shape clonedShape3 = (Shape) ShapeCache.getShape("3");
        System.out.println("Shape : " + clonedShape3.getType());
    }
}

结果：

Shape : Circle
Shape : Square
Shape : Rectangle

　　这种模式是实现了一个原型接口(Clonable)，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。

使用场景： 1、资源优化场景。 2、类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。 3、性能和安全要求的场景。 4、通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。 5、一个对象多个修改者的场景。 6、一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。 7、在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过 clone 的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与 Java 融为浑然一体，大家可以随手拿来使用。

创建型模式总结

　　创建型模式总体上比较简单，它们的作用就是为了产生实例对象，算是各种工作的第一步了，因为我们写的是面向对象 的代码，所以我们第一步当然是需要创建一个对象了。

　　简单工厂模式最简单；工厂模式在简单工厂模式的基础上增加了选择工厂的维度，需要第一步选择合适的工厂；抽象工厂模式有产品族的概念，如果各个产品是存在兼容性问题的，就要用抽象工厂模式。单例模式就不说了，为了保证全局使用的是同一对象，一方面是安全性考虑，一方面是为了节省资源；建造者模式专门对付属性很多的那种类，为了让代码更优美；原型模式用得最少，了解和 Object 类中的 clone() 方法相关的知识即可。

二、结构型模式Structural mode

前面创建型模式介绍了创建对象的一些设计模式，这节介绍的结构型模式旨在通过改变代码结构来达到解耦的目的，使得我们的代码容易维护和扩展。

1、代理模式the proxy pattern

　　第一个要介绍的代理模式是最常使用的模式之一了，用一个代理来隐藏具体实现类的实现细节，通常还用于在真实的实现的前后添加一部分逻辑。

　　既然说是代理，那就要对客户端隐藏真实实现，由代理来负责客户端的所有请求。当然，代理只是个代理，它不会完成实际的业务逻辑，而是一层皮而已，但是对于客户端来说，它必须表现得就是客户端需要的真实实现。

　　理解代理这个词，这个模式其实就简单了。

案例1：

Chicken子类

public class Chicken extends Food{
}

Noodle子类

public class Noodle extends Food{
}

Food父类

@Data
public class Food {
    String chicken;
    String spicy;
    String salt;
    String noodle;
    public void addSpicy(String str1) {
        System.out.println("加" + str1 + "辣");
    }
    public void addCondiment(String str2) {
        System.out.println("加" + str2);
    }
}

FoodService接口

public interface FoodService {
    Food makeChicken();
    Food makeNoodle();
}

FoodServiceImpl真实实现类

public class FoodServiceImpl implements FoodService{
    @Override
    public Food makeChicken() {
        Food f = new Chicken();
        f.setChicken("1kg");
        f.setSpicy("1g");
        f.setSalt("3g");
        return f;
    }

    @Override
    public Food makeNoodle() {
        Food f = new Noodle();
        f.setNoodle("500g");
        f.setSalt("5g");
        return f;
    }
}

FoodServiceProxy代理类

// 代理要表现得“就像是”真实实现类，所以需要实现 FoodService
public class FoodServiceProxy implements FoodService{
    // 内部一定要有一个真实的实现类，当然也可以通过构造方法注入
    private FoodService foodService = new FoodServiceImpl();
    @Override
    public Food makeChicken() {
        System.out.println("我们马上要开始制作鸡肉了");

        // 如果我们定义这句为核心代码的话，那么，核心代码是真实实现类做的，
        // 代理只是在核心代码前后做些“无足轻重”的事情
        Food food = foodService.makeChicken();

        System.out.println("鸡肉制作完成啦，加点胡椒粉"); // 增强
        food.addCondiment("pepper");

        return food;
    }

    @Override
    public Food makeNoodle() {
        System.out.println("准备制作拉面~");
        Food food = foodService.makeNoodle();
        System.out.println("制作完成啦");
        return food;
    }
}

客户端调用：

public class Client {
    public static void main(String[] args) {
        FoodService foodService = new FoodServiceProxy();
        foodService.makeChicken();
    }
}

注意，我们要用代理来实例化接口。

　　我们发现没有，代理模式说白了就是做 “方法包装” 或做 “方法增强” 。在面向切面编程中，其实就是动态代理的过程。比如 Spring 中，我们自己不定义代理类，但是 Spring 会帮我们动态来定义代理，然后把我们定义在 @Before、@After、@Around 中的代码逻辑动态添加到代理中。

　　说到动态代理，又可以展开说，Spring 中实现动态代理有两种，一种是如果我们的类定义了接口，如 UserService 接口和 UserServiceImpl 实现，那么采用 JDK 的动态代理，感兴趣的读者可以去看看 java.lang.reflect.Proxy 类的源码；另一种是我们自己没有定义接口的，Spring 会采用 CGLIB 进行动态代理，它是一个 jar 包，性能还不错。

基于接口的动态代理-案例2：

IProducer接口

public interface IProducer {
    // 销售
    public void saleProduct(float money);
    //售后
    public void afterService(float money);
}

Producer被代理对象

public class Producer implements IProducer{
    // 销售
    @Override
    public void saleProduct(float money) {
        System.out.println("销售产品，并拿到钱："+money);
    }
    //售后
    @Override
    public void afterService(float money) {
        System.out.println("提供售后服务，并拿到钱："+money);
    }
}

代理对象和客户端调用

public class Client {
    public static void main(String[] args) {
        // 被代理对象
        Producer producer = new Producer();
        // 创建代理对象
        IProducer proxyProducer = (IProducer)Proxy.newProxyInstance(producer.getClass().getClassLoader(), producer.getClass().getInterfaces(),
                new InvocationHandler() {
                    @Override
                    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                        //提供增强的代码
                        Object returnValue = null;
                        //1.获取方法执行的参数
                        Float money = (Float)args[0];
                        //2.判断当前方法是不是销售
                        if("saleProduct".equals(method.getName())) {
                            returnValue = method.invoke(producer, money*0.8f);
                        }
                        return returnValue;
                    }
                });
        proxyProducer.saleProduct(10000f);
    }
}

结果：销售产品，并拿到钱：8000.0

这消费者给的10000块钱，厂家只能拿到8000块钱，2000块钱是代理商的利润。

我们并没有在生产厂家（producer）的方法上进行任何的修改，但是已经对这个方法进行了增强。这就是基于接口的动态代理，但是它有一个问题：就是被代理类不实现任何接口的时候是不能用的，难道真的没有办法代理一个普通的java类吗？

基于子类的动态代理-案例：

1、添加依赖

<dependencies>
        <dependency>
            <groupId>cglib</groupId>
            <artifactId>cglib</artifactId>
            <version>2.1_3</version>
        </dependency>
    </dependencies>

2、Producer被代理类

public class Producer {
    // 销售
    public void saleProduct(float money) {
        System.out.println("销售产品，并拿到钱："+money);
    }
    //售后
    public void afterService(float money) {
        System.out.println("提供售后服务，并拿到钱："+money);
    }
}

3、创建被代理对象和客户端调用

public class Client {
    public static void main(String[] args) {
        // 被代理对象
        final Producer producer = new Producer();
        // 创建代理对象
        Producer cglibProducer = (Producer)Enhancer.create(producer.getClass(), new MethodInterceptor() {
            @Override
            public Object intercept(Object proxy, Method method, Object[] args1, MethodProxy methodProxy) throws Throwable {
                //提供增强的代码
                Object returnValue = null;
                //1.获取方法执行的参数
                Float money = (Float)args1[0];
                //2.判断当前方法是不是销售
                if("saleProduct".equals(method.getName())) {
                    returnValue = method.invoke(producer, money*0.8f);
                }
                return returnValue;
            }
        });
        cglibProducer.saleProduct(10000f);
    }
}

结果：销售产品，并拿到钱：8000.0

执行被代理对象的任何方法都会经过intercept方法。

基于接口的动态代理和基于子类的动态代理：参考https://www.cnblogs.com/zwh0910/p/14627120.html

2、适配器模式Adapter Pattern

说完代理模式，说适配器模式，是因为它们很相似，这里可以做个比较。

适配器模式做的就是，有一个接口需要实现，但是我们现成的对象都不满足，需要加一层适配器来进行适配。

适配器模式总体来说分三种：默认适配器模式、对象适配器模式、类适配器模式。先不急着分清楚这几个，先看看例子再说。

2.1、默认适配器模式default Adapter Pattern

首先，我们先看看最简单的适配器模式默认适配器模式(Default Adapter) 是怎么样的。

我们用 Appache commons-io 包中的 FileAlterationListener 做例子，此接口定义了很多的方法，用于对文件或文件夹进行监控，一旦发生了对应的操作，就会触发相应的方法。

public interface FileAlterationListener {
    void onStart(final FileAlterationObserver observer);
    void onDirectoryCreate(final File directory);
    void onDirectoryChange(final File directory);
    void onDirectoryDelete(final File directory);
    void onFileCreate(final File file);
    void onFileChange(final File file);
    void onFileDelete(final File file);
    void onStop(final FileAlterationObserver observer);
}

此接口的一大问题是抽象方法太多了，如果我们要用这个接口，意味着我们要实现每一个抽象方法，如果我们只是想要监控文件夹中的文件创建 和文件删除 事件，可是我们还是不得不实现所有的方法，很明显，这不是我们想要的。

所以，我们需要下面的一个适配器 ，它用于实现上面的接口，但是所有的方法都是空方法 ，这样，我们就可以转而定义自己的类来继承下面这个类即可。

1）、引入依赖

<dependencies>
        <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
            <version>2.5</version>
        </dependency>
    </dependencies>

2）、FileAlterationListenerAdaptor实现类

public class FileAlterationListenerAdaptor implements FileAlterationListener{
    @Override
    public void onStart(FileAlterationObserver observer) {

    }

    @Override
    public void onDirectoryCreate(File directory) {

    }

    @Override
    public void onDirectoryChange(File directory) {

    }

    @Override
    public void onDirectoryDelete(File directory) {

    }

    @Override
    public void onFileCreate(File file) {

    }

    @Override
    public void onFileChange(File file) {

    }

    @Override
    public void onFileDelete(File file) {

    }

    @Override
    public void onStop(FileAlterationObserver observer) {

    }
}

3）、FileMonitor子类

比如我们可以定义以下类，我们仅仅需要实现我们想实现的方法就可以了：

public class FileMonitor extends FileAlterationListenerAdaptor{
    public void onFileCreate(final File file) {
        // 文件创建
        // doSomething();
    }

    public void onFileDelete(final File file) {
        // 文件删除
        // doSomething();
    }
}

当然，上面说的只是适配器模式的其中一种，也是最简单的一种，无需多言。下面，再介绍**“正统的”** 适配器模式。

2.2、对象适配器模式Object Adapter Pattern

来看一个《Head First 设计模式》中的一个例子，我稍微修改了一下，看看怎么将鸡适配成鸭，这样鸡也能当鸭来用。因为，现在鸭这个接口，我们没有合适的实现类可以用，所以需要适配器。

Duck接口

public interface Duck {
    public void quack(); // 鸭的呱呱叫
    public void fly(); // 飞
}

Cock接口

public interface Cock {
    public void gobble(); // 鸡的咕咕叫
    public void fly(); // 飞
}

WildCock实现类

public class WildCock implements Cock{
    @Override
    public void gobble() {
        System.out.println("咕咕叫");
    }

    @Override
    public void fly() {
        System.out.println("鸡也会飞哦");
    }
}

鸭接口有 fly() 和 quare() 两个方法，鸡 Cock 如果要冒充鸭，fly() 方法是现成的，但是鸡不会鸭的呱呱叫，没有 quack() 方法。这个时候就需要适配了：

CockAdapter实现类

public class CockAdapter implements Duck{
    Cock cock;
    // 构造方法中需要一个鸡的实例，此类就是将这只鸡适配成鸭来用
    public CockAdapter(Cock cock) {
        this.cock = cock;
    }
    // 实现鸭的呱呱叫方法
    @Override
    public void quack() {
        // 内部其实是一只鸡的咕咕叫
        cock.gobble();
    }

    @Override
    public void fly() {
        cock.fly();
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        // 有一只野鸡
        Cock wildCock = new WildCock();
        // 成功将野鸡适配成鸭
        Duck duck = new CockAdapter(wildCock);
        duck.quack();
        duck.fly();
    }
}

结果:

咕咕叫
鸡也会飞哦

到这里，大家也就知道了适配器模式是怎么回事了。无非是我们需要一只鸭，但是我们只有一只鸡，这个时候就需要定义一个适配器，由这个适配器来充当鸭，但是适配器里面的方法还是由鸡来实现的。

我们用一个图来简单说明下：

上图应该还是很容易理解的，我就不做更多的解释了。下面，我们看看类适配模式怎么样的。

2.3、类适配器模式Adapter like pattern

废话少说，直接上图：

看到这个图，大家应该很容易理解的吧，通过继承的方法，适配器自动获得了所需要的大部分方法。这个时候，客户端使用更加简单，直接 Target t = new SomeAdapter(); 就可以了。

适配器模式总结

1、类适配和对象适配的异同

一个采用继承，一个采用组合；类适配属于静态实现，对象适配属于组合的动态实现，对象适配需要多实例化一个对象。总体来说，对象适配用得比较多。

2、适配器模式和代理模式的异同

　　比较这两种模式，其实是比较对象适配器模式和代理模式，在代码结构上，它们很相似，都需要一个具体的实现类的实例。但是它们的目的不一样，代理模式做的是增强原方法的活；适配器做的是适配的活，为的是提供“把鸡包装成鸭，然后当做鸭来使用”，而鸡和鸭它们之间原本没有继承关系。

3、桥梁模式bridge mode

理解桥梁模式，其实就是理解代码抽象和解耦。

我们首先需要一个桥梁，它是一个接口，定义提供的接口方法。

DrawAPI接口

public interface DrawAPI {
    void draw(int radius, int x, int y);
}

然后是一系列实现类：

RedPen实现类

public class RedPen implements DrawAPI{
    @Override
    public void draw(int radius, int x, int y) {
        System.out.println("用红色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
    }
}

GreenPen实现类

public class GreenPen implements DrawAPI{
    @Override
    public void draw(int radius, int x, int y) {
        System.out.println("用绿色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
    }
}

BluePen实现类

public class BluePen implements DrawAPI{
    @Override
    public void draw(int radius, int x, int y) {
        System.out.println("用蓝色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
    }
}

定义一个抽象类，此类的实现类都需要使用 DrawAPI：

Shape抽象类

public abstract class Shape {
    protected DrawAPI drawAPI;
    protected Shape(DrawAPI drawAPI) {
        this.drawAPI = drawAPI;
    }
    public abstract void draw();
}

定义抽象类的子类：

Circle子类

public class Circle extends Shape{
    private int radius;
    public Circle(int radius, DrawAPI drawAPI) {
        super(drawAPI);
        this.radius = radius;
    }
    @Override
    public void draw() {
        drawAPI.draw(radius, 0, 0);
    }
}

Rectangle子类

public class Rectangle extends Shape{
    private int x;
    private int y;
    public Rectangle(int x, int y, DrawAPI drawAPI) {
        super(drawAPI);
        this.x = x;
        this.y = y;
    }
    @Override
    public void draw() {
        drawAPI.draw(0, x, y);
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        Shape greenCircle = new Circle(10, new GreenPen());
        Shape redRectangle = new Rectangle(4, 8, new RedPen());
        greenCircle.draw();
        redRectangle.draw();
    }
}

结果：

用绿色笔画图，radius:10, x:0, y:0
用红色笔画图，radius:0, x:4, y:8

可能大家看上面一步步还不是特别清晰，我把所有的东西整合到一张图上：

这回大家应该就知道抽象在哪里，怎么解耦了吧。桥梁模式的优点也是显而易见的，就是非常容易进行扩展。

4、装饰模式decoration mode

要把装饰模式说清楚明白，不是件容易的事情。也许读者知道 Java IO 中的几个类是典型的装饰模式的应用，但是读者不一定清楚其中的关系，也许看完就忘了，希望看完这节后，读者可以对其有更深的感悟。

首先，我们先看一个简单的图，看这个图的时候，了解下层次结构就可以了：

　　我们来说说装饰模式的出发点，从图中可以看到，接口 Component 其实已经有了 ConcreteComponentA 和 ConcreteComponentB 两个实现类了，但是，如果我们要增强这两个实现类的话，我们就可以采用装饰模式，用具体的装饰器来装饰实现类，以达到增强的目的。

　　从名字来简单解释下装饰器。既然说是装饰，那么往往就是添加小功能 这种，而且，我们要满足可以添加多个小功能。最简单的，代理模式就可以实现功能的增强，但是代理不容易实现多个功能的增强，当然你可以说用代理包装代理的多层包装方式，但是那样的话代码就复杂了。

　　首先明白一些简单的概念，从图中我们看到，所有的具体装饰者们 ConcreteDecorator * 都可以作为 Component 来使用，因为它们都实现了 Component 中的所有接口。它们和 Component 实现类 ConcreteComponent* 的区别是，它们只是装饰者，起装饰作用，也就是即使它们看上去牛逼轰轰，但是它们都只是在具体的实现中加了层皮来装饰 而已。

注意这段话中混杂在各个名词中的 Component 和 Decorator，别搞混了。

下面来看看一个例子，先把装饰模式弄清楚，然后再介绍下 java io 中的装饰模式的应用。

　　最近大街上流行起来了“快乐柠檬”，我们把快乐柠檬的饮料分为三类：红茶、绿茶、咖啡，在这三大类的基础上，又增加了许多的口味，什么金桔柠檬红茶、金桔柠檬珍珠绿茶、芒果红茶、芒果绿茶、芒果珍珠红茶、烤珍珠红茶、烤珍珠芒果绿茶、椰香胚芽咖啡、焦糖可可咖啡等等，每家店都有很长的菜单，但是仔细看下，其实原料也没几样，但是可以搭配出很多组合，如果顾客需要，很多没出现在菜单中的饮料他们也是可以做的。

　　在这个例子中，红茶、绿茶、咖啡是最基础的饮料，其他的像金桔柠檬、芒果、珍珠、椰果、焦糖等都属于装饰用的。当然，在开发中，我们确实可以像门店一样，开发这些类：LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea......但是，很快我们就发现，这样子干肯定是不行的，这会导致我们需要组合出所有的可能，而且如果客人需要在红茶中加双份柠檬怎么办？三份柠檬怎么办？

不说废话了，上代码。

首先，定义饮料抽象基类：

Beverage抽象类

public abstract class Beverage {
    // 返回描述
    public abstract String getDescription();
    // 返回价格
    public abstract double cost();
}

然后是三个基础饮料实现类，红茶、绿茶和咖啡：

BlackTea子类

public class BlackTea extends Beverage{
    @Override
    public String getDescription() {
        return "红茶";
    }

    @Override
    public double cost() {
        return 10;
    }
}

GreenTea子类

public class GreenTea extends Beverage{
    @Override
    public String getDescription() {
        return "绿茶";
    }

    @Override
    public double cost() {
        return 11;
    }
}

Coffee子类

public class Coffee extends Beverage{
    @Override
    public String getDescription() {
        return "咖啡";
    }

    @Override
    public double cost() {
        return 12;
    }
}

定义调料，也就是装饰者的基类，此类必须继承自 Beverage：

Condiment抽象类

public abstract class Condiment extends Beverage{
}

然后我们来定义柠檬、芒果等具体的调料，它们属于装饰者，毫无疑问，这些调料肯定都需要继承调料 Condiment 类：

Lemon子类

public class Lemon extends Condiment{
    private Beverage beverage;
    // 这里很关键，需要传入具体的饮料，如需要传入没有被装饰的红茶或绿茶，
    // 当然也可以传入已经装饰好的芒果绿茶，这样可以做芒果柠檬绿茶
    public Lemon(Beverage beverage) {
        this.beverage = beverage;
    }
    @Override
    public String getDescription() {
        // 装饰
        return beverage.getDescription() + ", 加柠檬";
    }

    @Override
    public double cost() {
        // 装饰
        return beverage.cost() + 2; // 加柠檬需要 2 元
    }
}

Mango子类

public class Mango extends Condiment{
    private Beverage beverage;
    public Mango(Beverage beverage) {
        this.beverage = beverage;
    }
    @Override
    public String getDescription() {
        return beverage.getDescription() + ", 加芒果";
    }

    @Override
    public double cost() {
        return beverage.cost() + 3; // 加芒果需要 3 元
    }
}

Pearl子类

public class Pearl extends Condiment{
    private Beverage beverage;
    public Pearl(Beverage beverage) {
        this.beverage = beverage;
    }
    @Override
    public String getDescription() {
        return beverage.getDescription() + ", 加珍珠";
    }

    @Override
    public double cost() {
        return beverage.cost() + 1; // 加珍珠需要 1 元
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        // 首先，我们需要一个基础饮料，红茶、绿茶或咖啡
        Beverage beverage = new GreenTea();
        // 开始装饰
        beverage = new Lemon(beverage); // 先加一份柠檬
        beverage = new Mango(beverage); // 再加一份芒果

        System.out.println(beverage.getDescription() + " 价格：￥" + beverage.cost());
        //"绿茶, 加柠檬, 加芒果 价格：￥16"
    }
}

结果：绿茶, 加柠檬, 加芒果价格：￥16.0

如果我们需要 芒果-珍珠-双份柠檬-红茶 ：

public class Client {
    public static void main(String[] args) {
        Beverage beverage1 = new Mango(new Pearl(new Lemon(new Lemon(new BlackTea()))));
        System.out.println(beverage1.getDescription() + " 价格：￥" + beverage1.cost());
    }
}

结果：红茶, 加柠檬, 加柠檬, 加珍珠, 加芒果价格：￥18.0

是不是很变态？

看看下图可能会清晰一些：

到这里，大家应该已经清楚装饰模式了吧。

下面，我们再来说说 java IO 中的装饰模式。看下图 InputStream 派生出来的部分类：

　　我们知道 InputStream 代表了输入流，具体的输入来源可以是文件（FileInputStream）、管道（PipedInputStream）、数组（ByteArrayInputStream）等，这些就像前面奶茶的例子中的红茶、绿茶，属于基础输入流。

　　FilterInputStream 承接了装饰模式的关键节点，它的实现类是一系列装饰器，比如 BufferedInputStream 代表用缓冲来装饰，也就使得输入流具有了缓冲的功能，LineNumberInputStream 代表用行号来装饰，在操作的时候就可以取得行号了，DataInputStream 的装饰，使得我们可以从输入流转换为 java 中的基本类型值。

当然，在 java IO 中，如果我们使用装饰器的话，就不太适合面向接口编程了，如：

InputStream inputStream = new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));

这样的结果是，InputStream 还是不具有读取行号的功能，因为读取行号的方法定义在 LineNumberInputStream 类中。

我们应该像下面这样使用：

DataInputStream is = new DataInputStream(
                              new BufferedInputStream(
                                  new FileInputStream("")));

所以说嘛，要找到纯的严格符合设计模式的代码还是比较难的。

5、门面模式facade mode

　　门面模式（也叫外观模式，Facade Pattern）在许多源码中有使用，比如 slf4j 就可以理解为是门面模式的应用。这是一个简单的设计模式，我们直接上代码再说吧。

首先，我们定义一个接口：

public interface Shape {
    void draw();
}

定义几个实现类：

Circle实现类

public class Circle implements Shape{
    @Override
    public void draw() {
        System.out.println("Circle::draw()");
    }
}

Rectangle实现类‘

public class Rectangle implements Shape{
    @Override
    public void draw() {
        System.out.println("Rectangle::draw()");
    }
}

Square实现类

public class Square implements Shape{
    @Override
    public void draw() {
        System.out.println("Square::draw()");
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        // 画一个圆形
        Shape circle = new Circle();
        circle.draw();
        // 画一个长方形
        Shape rectangle = new Rectangle();
        rectangle.draw();
    }
}

以上是我们常写的代码，我们需要画圆就要先实例化圆，画长方形就需要先实例化一个长方形，然后再调用相应的 draw() 方法。

下面，我们看看怎么用门面模式来让客户端调用更加友好一些。

我们先定义一个门面：

public class ShapeMaker {
    private Shape circle;
    private Shape rectangle;
    private Shape square;

    public ShapeMaker() {
        circle = new Circle();
        rectangle = new Rectangle();
        square = new Square();
    }

    /**
     * 下面定义一堆方法，具体应该调用什么方法，由这个门面来决定
     */

    public void drawCircle(){
        circle.draw();
    }
    public void drawRectangle(){
        rectangle.draw();
    }
    public void drawSquare(){
        square.draw();
    }
}

看看现在客户端怎么调用：

public class Client1 {
    public static void main(String[] args) {
        ShapeMaker shapeMaker = new ShapeMaker();

        // 客户端调用现在更加清晰了
        shapeMaker.drawCircle();
        shapeMaker.drawRectangle();
        shapeMaker.drawSquare();
    }
}

结果如下:

Circle::draw()
Rectangle::draw()
Square::draw()

门面模式的优点显而易见，客户端不再需要关注实例化时应该使用哪个实现类，直接调用门面提供的方法就可以了，因为门面类提供的方法的方法名对于客户端来说已经很友好了。

6、组合模式portfolio model

组合模式用于表示具有层次结构的数据，使得我们对单个对象和组合对象的访问具有一致性。

直接看一个例子吧，每个员工都有姓名、部门、薪水这些属性，同时还有下属员工集合（虽然可能集合为空），而下属员工和自己的结构是一样的，也有姓名、部门这些属性，同时也有他们的下属员工集合。

Employee实体类

public class Employee {
    private String name;
    private String dept;
    private int salary;
    private List<Employee> subordinates; // 下属

    public Employee(String name,String dept, int sal) {
        this.name = name;
        this.dept = dept;
        this.salary = sal;
        subordinates = new ArrayList<Employee>();
    }

    public void add(Employee e) {
        subordinates.add(e);
    }

    public void remove(Employee e) {
        subordinates.remove(e);
    }

    public List<Employee> getSubordinates(){
        return subordinates;
    }

    public String toString(){
        return ("Employee :[ Name : " + name + ", dept : " + dept + ", salary :" + salary+" ]");
    }
}

通常，这种类需要定义 add(node)、remove(node)、getChildren() 这些方法。

客户端调用

public class Client {
    public static void main(String[] args) {
        Employee CEO = new Employee("John","CEO", 30000);

        Employee headSales = new Employee("Robert","Head Sales", 20000);

        Employee headMarketing = new Employee("Michel","Head Marketing", 20000);

        Employee clerk1 = new Employee("Laura","Marketing", 10000);
        Employee clerk2 = new Employee("Bob","Marketing", 10000);

        Employee salesExecutive1 = new Employee("Richard","Sales", 10000);
        Employee salesExecutive2 = new Employee("Rob","Sales", 10000);

        CEO.add(headSales);
        CEO.add(headMarketing);

        headSales.add(salesExecutive1);
        headSales.add(salesExecutive2);

        headMarketing.add(clerk1);
        headMarketing.add(clerk2);

        //打印该组织的所有员工
        System.out.println(CEO);
        for (Employee headEmployee : CEO.getSubordinates()) {
            System.out.println(headEmployee);
            for (Employee employee : headEmployee.getSubordinates()) {
                System.out.println(employee);
            }
        }
    }
}

结果：

Employee :[ Name : John, dept : CEO, salary :30000 ]
Employee :[ Name : Robert, dept : Head Sales, salary :20000 ]
Employee :[ Name : Richard, dept : Sales, salary :10000 ]
Employee :[ Name : Rob, dept : Sales, salary :10000 ]
Employee :[ Name : Michel, dept : Head Marketing, salary :20000 ]
Employee :[ Name : Laura, dept : Marketing, salary :10000 ]
Employee :[ Name : Bob, dept : Marketing, salary :10000 ]

这说的其实就是组合模式，这种简单的模式我就不做过多介绍了，相信各位读者也不喜欢看我写废话。

7、享元模式the flyweight pattern

英文是 Flyweight Pattern，不知道是谁最先翻译的这个词，感觉这翻译真的不好理解，我们试着强行关联起来吧。Flyweight 是轻量级的意思，享元分开来说就是共享元器件，也就是复用已经生成的对象，这种做法当然也就是轻量级的了。

复用对象最简单的方式是，用一个 HashMap 来存放每次新生成的对象。每次需要一个对象的时候，先到 HashMap 中看看有没有，如果没有，再生成新的对象，然后将这个对象放入 HashMap 中。

案例：

我们将创建一个 Shape 接口和实现了 Shape 接口的实体类 Circle。下一步是定义工厂类 ShapeFactory。ShapeFactory 有一个 Circle 的 HashMap，其中键名为 Circle 对象的颜色。无论何时接收到请求，都会创建一个特定颜色的圆。ShapeFactory 检查它的 HashMap 中的 circle 对象，如果找到 Circle 对象，则返回该对象，否则将创建一个存储在 hashmap 中以备后续使用的新对象，并把该对象返回到客户端。

Shape接口

public interface Shape {
    void draw();
}

Circle实现类

public class Circle implements Shape{
    private String color;
    private int x;
    private int y;
    private int radius;

    public Circle(String color){
        this.color = color;
    }

    public void setX(int x) {
        this.x = x;
    }

    public void setY(int y) {
        this.y = y;
    }

    public void setRadius(int radius) {
        this.radius = radius;
    }
    @Override
    public void draw() {
        System.out.println("Circle: Draw() [Color : " + color
                +", x : " + x +", y :" + y +", radius :" + radius);
    }
}

创建一个工厂，生成基于给定信息的实体类的对象

ShapeFactory工厂

public class ShapeFactory {
    private static final HashMap<String, Shape> circleMap = new HashMap<>();
    // 使用 ShapeFactory 来获取 Shape 对象
    public static Shape getCircle(String color) {
        Circle circle = (Circle)circleMap.get(color);

        if(circle == null) {
            circle = new Circle(color);
            circleMap.put(color, circle);
            System.out.println("Creating circle of color : " + color);
        }
        return circle;
    }
}

客户端调用

public class Client {
    private static final String colors[] = { "Red", "Green", "Blue", "White", "Black" };
    public static void main(String[] args) {
        for(int i=0; i < 20; ++i) {
            Circle circle = (Circle)ShapeFactory.getCircle(getRandomColor());
            circle.setX(getRandomX());
            circle.setY(getRandomY());
            circle.setRadius(100);
            circle.draw();
        }
    }
    private static String getRandomColor() {
        // Math.random()是令系统随机选取大于等于 0.0 且小于 1.0 的伪随机 double 值
        return colors[(int)(Math.random()*colors.length)];
    }
    private static int getRandomX() {
        return (int)(Math.random()*100 );
    }
    private static int getRandomY() {
        return (int)(Math.random()*100);
    }
}

结果：

Creating circle of color : Black
Circle: Draw() [Color : Black, x : 60, y :89, radius :100
Creating circle of color : White
Circle: Draw() [Color : White, x : 0, y :10, radius :100
Creating circle of color : Red
Circle: Draw() [Color : Red, x : 54, y :31, radius :100
Circle: Draw() [Color : White, x : 50, y :36, radius :100
Circle: Draw() [Color : Black, x : 80, y :39, radius :100
Circle: Draw() [Color : Red, x : 64, y :53, radius :100
Circle: Draw() [Color : Black, x : 40, y :60, radius :100
Circle: Draw() [Color : White, x : 85, y :16, radius :100
Circle: Draw() [Color : Red, x : 46, y :30, radius :100
Circle: Draw() [Color : White, x : 79, y :78, radius :100
Creating circle of color : Green
Circle: Draw() [Color : Green, x : 40, y :22, radius :100
Creating circle of color : Blue
Circle: Draw() [Color : Blue, x : 44, y :61, radius :100
Circle: Draw() [Color : Green, x : 43, y :95, radius :100
Circle: Draw() [Color : Red, x : 32, y :48, radius :100
Circle: Draw() [Color : Blue, x : 78, y :53, radius :100
Circle: Draw() [Color : Red, x : 97, y :82, radius :100
Circle: Draw() [Color : Black, x : 78, y :11, radius :100
Circle: Draw() [Color : Red, x : 47, y :91, radius :100
Circle: Draw() [Color : White, x : 71, y :87, radius :100
Circle: Draw() [Color : Blue, x : 9, y :25, radius :100

结构型模式总结

　　前面，我们说了代理模式、适配器模式、桥梁模式、装饰模式、门面模式、组合模式和享元模式。读者是否可以分别把这几个模式说清楚了呢？在说到这些模式的时候，心中是否有一个清晰的图或处理流程在脑海里呢？

代理模式是做方法增强的，适配器模式是把鸡包装成鸭这种用来适配接口的，桥梁模式做到了很好的解耦，装饰模式从名字上就看得出来，适合于装饰类或者说是增强类的场景，门面模式的优点是客户端不需要关心实例化过程，只要调用需要的方法即可，组合模式用于描述具有层次结构的数据，享元模式是为了在特定的场景中缓存已经创建的对象，用于提高性能。

三、行为型模式Behavioral patterns

行为型模式关注的是各个类之间的相互作用，将职责划分清楚，使得我们的代码更加地清晰。

1、策略模式the strategy pattern

策略模式太常用了，所以把它放到最前面进行介绍。它比较简单，我就不废话，直接用代码说事吧。

下面设计的场景是，我们需要画一个图形，可选的策略就是用红色笔来画，还是绿色笔来画，或者蓝色笔来画。

首先，先定义一个策略接口：

Strategy接口

public interface Strategy {
    void draw(int radius, int x, int y);
}

然后我们定义具体的几个策略：

RedPen实现类

public class RedPen implements Strategy{
    @Override
    public void draw(int radius, int x, int y) {
        System.out.println("用红色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
    }
}

GreenPen实现类

public class GreenPen implements Strategy{
    @Override
    public void draw(int radius, int x, int y) {
        System.out.println("用绿色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
    }
}

BluePen实现类

public class BluePen implements Strategy{
    @Override
    public void draw(int radius, int x, int y) {
        System.out.println("用蓝色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
    }
}

使用策略的类：

public class Context {
    private Strategy strategy;

    public Context(Strategy strategy){
        this.strategy = strategy;
    }
    public void executeDraw(int radius, int x, int y){
        strategy.draw(radius, x, y);
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        Context context = new Context(new BluePen()); // 使用绿色笔来画
        context.executeDraw(10, 0, 0);
    }
}

结果：用蓝色笔画图，radius:10, x:0, y:0

放到一张图上，让大家看得清晰些：

这个时候，大家有没有联想到结构型模式中的桥梁模式，它们其实非常相似，我把桥梁模式的图拿过来大家对比下：

要我说的话，它们非常相似，桥梁模式在左侧加了一层抽象而已。桥梁模式的耦合更低，结构更复杂一些。

2、观察者模式Observer mode

观察者模式对于我们来说，真是再简单不过了。无外乎两个操作，观察者订阅自己关心的主题和主题有数据变化后通知观察者们。

首先，需要定义主题，每个主题需要持有观察者列表的引用，用于在数据变更的时候通知各个观察者：

定义观察者抽象类：

public abstract class Observer {
    protected Subject subject;
    public abstract void update();
}

需要定义主题，每个主题需要持有观察者列表的引用，用于在数据变更的时候通知各个观察者：

public class Subject {
    private List<Observer> observers = new ArrayList<Observer>();
    private int state;
    public int getState() {
        return state;
    }
    public void setState(int state) {
        this.state = state;
        // 数据已变更，通知观察者们
        notifyAllObservers();
    }
    // 注册观察者
    public void attach(Observer observer) {
        observers.add(observer);
    }
    // 通知观察者们
    public void notifyAllObservers() {
        for (Observer observer : observers) {
            observer.update();
        }
    }
}

其实如果只有一个观察者类的话，接口都不用定义了，不过，通常场景下，既然用到了观察者模式，我们就是希望一个事件出来了，会有多个不同的类需要处理相应的信息。比如，订单修改成功事件，我们希望发短信的类得到通知、发邮件的类得到通知、处理物流信息的类得到通知等。

我们来定义具体的几个观察者类：

BinaryObserver子类

public class BinaryObserver extends Observer{
    // 在构造方法中进行订阅主题
    public BinaryObserver(Subject subject) {
        this.subject = subject;
        // 通常在构造方法中将 this 发布出去的操作一定要小心
        this.subject.attach(this); // 注册到observers
    }
    @Override
    public void update() {
        String result = Integer.toBinaryString(subject.getState());
        System.out.println("订阅的数据发生变化，新的数据处理为二进制值为：" + result);
    }
}

HexaObserver子类

public class HexaObserver extends Observer{
    public HexaObserver(Subject subject) {
        this.subject = subject;
        this.subject.attach(this); // 注册到observers
    }
    @Override
    public void update() {
        String result = Integer.toHexString(subject.getState()).toUpperCase();
        System.out.println("订阅的数据发生变化，新的数据处理为十六进制值为：" + result);
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        // 先定义一个主题
        Subject subject1 = new Subject();
        // 定义观察者
        new BinaryObserver(subject1);
        new HexaObserver(subject1);
        // 模拟数据变更，这个时候，观察者们的 update 方法将会被调用
        subject1.setState(11); // 遍历observers并调用update方法
    }
}

结果：

订阅的数据发生变化，新的数据处理为二进制值为：1011
订阅的数据发生变化，新的数据处理为十六进制值为：B

当然，jdk 也提供了相似的支持，具体的大家可以参考 java.util.Observable 和 java.util.Observer 这两个类。

　　实际生产过程中，观察者模式往往用消息中间件来实现，如果要实现单机观察者模式，笔者建议读者使用 Guava 中的 EventBus，它有同步实现也有异步实现，本文主要介绍设计模式，就不展开说了。

　　还有，即使是上面的这个代码，也会有很多变种，大家只要记住核心的部分，那就是一定有一个地方存放了所有的观察者，然后在事件发生的时候，遍历观察者，调用它们的回调函数。

3、责任链模式The chain of responsibility model

　　责任链通常需要先建立一个单向链表，然后调用方只需要调用头部节点就可以了，后面会自动流转下去。比如流程审批就是一个很好的例子，只要终端用户提交申请，根据申请的内容信息，自动建立一条责任链，然后就可以开始流转了。

　　有这么一个场景，用户参加一个活动可以领取奖品，但是活动需要进行很多的规则校验然后才能放行，比如首先需要校验用户是否是新用户、今日参与人数是否有限额、全场参与人数是否有限额等等。设定的规则都通过后，才能让用户领走奖品。

　　如果产品给你这个需求的话，我想大部分人一开始肯定想的就是，用一个 List 来存放所有的规则，然后 foreach 执行一下每个规则就好了。不过，读者也先别急，看看责任链模式和我们说的这个有什么不一样？

首先，我们要定义流程上节点的基类：

RuleHandler抽象类

public abstract class RuleHandler {
    // 后继节点
    protected RuleHandler successor;

    public abstract void apply(Context context);

    public void setSuccessor(RuleHandler successor) {
        this.successor = successor;
    }

    public RuleHandler getSuccessor() {
        return successor;
    }
}

Context实体类

@Data
public class Context {
    Boolean isNewUser;
    String location;
}

接下来，我们需要定义具体的每个节点了。

校验用户是否是新用户：

public class NewUserRuleHandler extends RuleHandler{
    @Override
    public void apply(Context context) {
        if (context.getIsNewUser()) {
            // 如果有后继节点的话，传递下去
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(context);
            }
        } else {
            throw new RuntimeException("该活动仅限新用户参与");
        }
    }
}

校验用户所在地区是否可以参与：

public class LocationRuleHandler extends RuleHandler{
    @Override
    public void apply(Context context) {
//        boolean allowed = activityService.isSupportedLocation(context.getLocation());
        // allowed设置为true来模拟地区校验成功
        boolean allowed = false;
        if (allowed) {
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(context);
            }
        } else {
            throw new RuntimeException("非常抱歉，您所在的地区无法参与本次活动");
        }
    }
}

校验奖品是否已领完：

public class LimitRuleHandler extends RuleHandler{
    @Override
    public void apply(Context context) {
        // int remainedTimes = activityService.queryRemainedTimes(context); // 查询剩余奖品
        // 设置remainedTimes值为1来模拟还有剩余奖品
        int remainedTimes = 1;
        if (remainedTimes > 0) {
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(context);
            }
        } else {
            throw new RuntimeException("您来得太晚了，奖品被领完了");
        }
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        Context context = new Context();
        context.setIsNewUser(true);
        context.setLocation("武汉");
        RuleHandler newUserHandler = new NewUserRuleHandler();
        RuleHandler locationHandler = new LocationRuleHandler();
        RuleHandler limitHandler = new LimitRuleHandler();

        // 假设本次活动仅校验地区和奖品数量，不校验新老用户
        locationHandler.setSuccessor(limitHandler);

        locationHandler.apply(context);
    }
}

结果：

Exception in thread "main" java.lang.RuntimeException: 非常抱歉，您所在的地区无法参与本次活动
    at com.zwh.chainOfResponsibility.LocationRuleHandler.apply(LocationRuleHandler.java:19)
    at com.zwh.chainOfResponsibility.Client.main(Client.java:20)

代码其实很简单，就是先定义好一个链表，然后在通过任意一节点后，如果此节点有后继节点，那么传递下去。

至于它和我们前面说的用一个 List 存放需要执行的规则的做法有什么异同，留给读者自己琢磨吧。

4、模板方法模式template method pattern

在含有继承结构的代码中，模板方法模式是非常常用的。

通常会有一个抽象类：

AbstractTemplate抽象类

public abstract class AbstractTemplate {
    // 这就是模板方法
    public void templateMethod() {
        init();
        apply(); // 这个是重点
        end(); // 可以作为钩子方法
    }

    protected void init() {
        System.out.println("init 抽象层已经实现，子类也可以选择覆写");
    }

    // 留给子类实现
    protected abstract void apply();

    protected void end() {
    }
}

　　模板方法中调用了 3 个方法，其中 apply() 是抽象方法，子类必须实现它，其实模板方法中有几个抽象方法完全是自由的，我们也可以将三个方法都设置为抽象方法，让子类来实现。也就是说，模板方法只负责定义第一步应该要做什么，第二步应该做什么，第三步应该做什么，至于怎么做，由子类来实现。

我们写一个实现类：

public class ConcreteTemplate extends AbstractTemplate{
    @Override
    protected void apply() {
        System.out.println("子类实现抽象方法 apply");
    }
    public void end() {
        System.out.println("我们可以把 method3 当做钩子方法来使用，需要的时候覆写就可以了");
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        AbstractTemplate t = new ConcreteTemplate();
        // 调用模板方法
        t.templateMethod();
    }
}

结果：

init 抽象层已经实现，子类也可以选择覆写
子类实现抽象方法 apply
我们可以把 method3 当做钩子方法来使用，需要的时候覆写就可以了

代码其实很简单，基本上看到就懂了，关键是要学会用到自己的代码中。

5、状态模式the state pattern

废话我就不说了，我们说一个简单的例子。商品库存中心有个最基本的需求是减库存和补库存，我们看看怎么用状态模式来写。

核心在于，我们的关注点不再是 Context 是该进行哪种操作，而是关注在这个 Context 会有哪些操作。

定义状态接口：

State接口

public interface State {
    void doAction(Context context);
}

定义减库存的状态：

public class DeductState implements State{
    @Override
    public void doAction(Context context) {
        System.out.println("商品卖出，准备减库存");
        context.setState(this);

        //... 执行减库存的具体操作
    }
    public String toString() {
        return "Deduct State";
    }
}

定义补库存状态：

public class RevertState implements State{
    @Override
    public void doAction(Context context) {
        System.out.println("给此商品补库存");
        context.setState(this);

        //... 执行加库存的具体操作
    }
    public String toString() {
        return "Revert State";
    }
}

前面用到了 context.setState(this)，我们来看看怎么定义 Context 类：

public class Context {
    private State state;
    private String name;
    public Context(String name) {
        this.name = name;
    }

    public void setState(State state) {
        this.state = state;
    }
    public State getState() {
        return this.state;
    }
}

客户端调用

public class Client {
    public static void main(String[] args) {
        // 我们需要操作的是 iPhone X
        Context context = new Context("iPhone X");

        // 看看怎么进行补库存操作
        State revertState = new RevertState();
        revertState.doAction(context);

        // 同样的，减库存操作也非常简单
        State deductState = new DeductState();
        deductState.doAction(context);

        // 如果需要我们可以获取当前的状态
        // context.getState().toString();
    }
}

结果：

给此商品补库存
商品卖出，准备减库存

读者可能会发现，在上面这个例子中，如果我们不关心当前 context 处于什么状态，那么 Context 就可以不用维护 state 属性了，那样代码会简单很多。

不过，商品库存这个例子毕竟只是个例，我们还有很多实例是需要知道当前 context 处于什么状态的。

行为型模式总结

行为型模式部分介绍了策略模式、观察者模式、责任链模式、模板方法模式和状态模式，其实，经典的行为型模式还包括备忘录模式、命令模式等，但是它们的使用场景比较有限，而且本文篇幅也挺大了，我就不进行介绍了。

四、总结

　　学习设计模式的目的是为了让我们的代码更加的优雅、易维护、易扩展。这次整理这篇文章，让我重新审视了一下各个设计模式，对我自己而言收获还是挺大的。我想，文章的最大收益者一般都是作者本人，为了写一篇文章，需要巩固自己的知识，需要寻找各种资料，而且，自己写过的才最容易记住，也算是我给读者的建议吧。

posted on 2022-10-11 11:34 周文豪阅读(98) 评论(0) 编辑收藏举报