JAVA后端开发面试基础知识（十）——设计模式

创建型模式

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

1. 单例模式
2. 简单工厂模式
3. 工厂模式
4. 抽象工厂模式
5. 建造者模式
6. 原型模式

结构型模式

结构型模式旨在通过改变代码结构来达到解耦的目的，使得我们的代码容易维护和扩展。

1. 代理模式
2. 适配器模式
3. 桥梁模式
4. 装饰模式
5. 门面模式
6. 组合模式
7. 享元模式

行为型模式

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

1. 策略模式
2. 观察者模式
3. 责任链模式
4. 模版方法模式
5. 状态模式

单例模式（单线程）

保证一个类只有一个实例，并且提供一个访问该全局访问点。

• 应用：

  • 网站的计数器，一般也是采用单例模式实现，否则难以同步。
  • 应用程序的日志应用，一般都是单例模式实现，只有一个实例去操作才好，否则内容不好追加显示。
  • 多线程的线程池的设计一般也是采用单例模式，因为线程池要方便对池中的线程进行控制
  • Windows的(任务管理器)就是很典型的单例模式，他不能打开俩个
  • windows的(回收站)也是典型的单例应用。在整个系统运行过程中，回收站只维护一个实例。

• 优点:

  1. 在单例模式中，活动的单例只有一个实例，对单例类的所有实例化得到的都是相同的一个实例。这样就防止其它对象对自己的实例化，确保所有的对象都访问一个实例
  2. 单例模式具有一定的伸缩性，类自己来控制实例化进程，类就在改变实例化进程上有相应的伸缩性。
  3. 提供了对唯一实例的受控访问。
  4. 由于在系统内存中只存在一个对象，因此可以节约系统资源，当需要频繁创建和销毁的对象时单例模式无疑可以提高系统的性能。
  5. 允许可变数目的实例。
  6. 避免对共享资源的多重占用。

• 缺点:

  1. 不适用于变化的对象，如果同一类型的对象总是要在不同的用例场景发生变化，单例就会引起数据的错误，不能保存彼此的状态。

  2. 由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。

  3. 单例类的职责过重，在一定程度上违背了“单一职责原则”。

  4. 滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为是垃圾而被回收，这将导致对象状态的丢失。

• 创建方式

  如果不需要延迟加载单例，可以使用枚举或者饿汉式，相对来说枚举性好于饿汉式。

  如果需要延迟加载，可以使用静态内部类或者懒汉式，相对来说静态内部类好于懒汉式。 最好使用饿汉式

  • 饿汉式：类初始化时，会立即加载该对象，线程天生安全，调用效率高。

  public class Singleton {
      // 首先，将 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 class Singleton {
      // 首先，也是先堵死 new Singleton() 这条路
      private Singleton() {}
      // 和饿汉模式相比，这边不需要先实例化出来，注意这里的 volatile，它是必须的
    	// 双重检查，指的是两次检查 instance 是否为 null。
      private static volatile Singleton instance = null;
  
      public static Singleton getInstance() {
          if (instance == null) {
              // 加锁
              synchronized (Singleton.class) {
                  // 这一次判断也是必须的，不然会有并发问题
                  if (instance == null) {
                      instance = new Singleton();
                  }
              }
          }
          return instance;
      }
  }
  

  • 静态内部方式（嵌套类）：结合了懒汉式和饿汉式各自的优点，真正需要对象的时候才会加载，加载类是线程安全的。

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

  • 枚举单例：使用枚举实现单例模式。优点：实现简单、调用效率高，枚举本身就是单例，由jvm从根本上提供保障，避免通过反射和反序列化的漏洞， 缺点没有延迟加载。

工厂模式（Bean）

它提供了一种创建对象的最佳方式。在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。实现了创建者和调用者分离。

• 分类

  • 简单工厂：用来生产同一等级结构中的任意产品。(不支持拓展增加产品)

    简单工厂模式相当于是一个工厂中有各种产品，创建在一个类中，客户无需知道具体产品的名称，只需要知道产品类所对应的参数即可。但是工厂的职责过重，而且当类型过多时不利于系统的扩展维护。

    • 优点：简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。明确区分了各自的职责和权力，有利于整个软件体系结构的优化。
    • 缺点：很明显工厂类集中了所有实例的创建逻辑，容易违反GRASPR的高内聚的责任分配原则

  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;
          }
      }
  }
  

  • 工厂方法：用来生产同一等级结构中的固定产品。(支持拓展增加产品)

    又称多态性工厂模式。在工厂方法模式中，核心的工厂类不再负责所有的产品的创建，而是将具体创建的工作交给子类去做。该核心类成为一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

  public interface FoodFactory {
      Food makeFood(String name);
  }
  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;
          }
      }
  }
  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;
          }
      }
  }
  
  // 调用
  public class APP {
      public static void main(String[] args) {
          // 先选择一个具体的工厂
          FoodFactory factory = new ChineseFoodFactory();
          // 由第一步的工厂产生具体的对象，不同的工厂造出不一样的对象
          Food food = factory.makeFood("A");
      }
  }
  

  • 抽象工厂模式：用来生产不同产品族的全部产品。(不支持拓展增加产品；支持增加产品族)

    抽象工厂简单地说是工厂的工厂，抽象工厂可以创建具体工厂，由具体工厂来产生具体产品。

  // 得到 Intel 的 CPU
  CPUFactory cpuFactory = new IntelCPUFactory();
  CPU cpu = intelCPUFactory.makeCPU();
  
  // 得到 AMD 的主板
  MainBoardFactory mainBoardFactory = new AmdMainBoardFactory();
  MainBoard mainBoard = mainBoardFactory.make();
  
  // 组装 CPU 和主板
  Computer computer = new Computer(cpu, mainBoard);
  
  public static void main(String[] args) {
      // 第一步就要选定一个“大厂”
      ComputerFactory cf = new AmdFactory();
      // 从这个大厂造 CPU
      CPU cpu = cf.makeCPU();
      // 从这个大厂造主板
      MainBoard board = cf.makeMainBoard();
    	// 从这个大厂造硬盘
    	HardDisk hardDisk = cf.makeHardDisk();
      // 将同一个厂子出来的 CPU、主板、硬盘组装在一起
      Computer result = new Computer(cpu, board, hardDisk);
  }
  

• 优点

  • 工厂模式是我们最常用的实例化对象模式了，是用工厂方法代替new操作的一种模式。
  • 利用工厂模式可以降低程序的耦合性，为后期的维护修改提供了很大的便利。
  • 将选择实现类、创建对象统一管理和控制。从而将调用者跟我们的实现类解耦。

• Spring开发中的工厂设计模式

  • Spring IOC

    • 在Spring IOC容器创建bean的过程是使用了工厂设计模式
    • Spring中无论是通过xml配置还是通过配置类还是注解进行创建bean，大部分都是通过简单工厂来进行创建的。
    • 当容器拿到了beanName和class类型后，动态的通过反射创建具体的某个对象，最后将创建的对象放到Map中。

  • 为什么Spring IOC要使用工厂设计模式创建Bean呢

    • 在实际开发中，如果我们A对象调用B，B调用C，C调用D的话我们程序的耦合性就会变高。(耦合大致分为类与类之间的依赖，方法与方法之间的依赖。)
    • 在很久以前的三层架构编程时，都是控制层调用业务层，业务层调用数据访问层时，都是是直接new对象，耦合性大大提升，代码重复量很高，对象满天飞
    • 为了避免这种情况，Spring使用工厂模式编程，写一个工厂，由工厂创建Bean，以后我们如果要对象就直接管工厂要就可以，剩下的事情不归我们管了。Spring IOC容器的工厂中有个静态的 Map集合，是为了让工厂符合单例设计模式，即每个对象只生产一次，生产出对象后就存入到 Map集合中，保证了实例不会重复影响程序效率

原型模式（克隆）

• 原型设计模式简单来说就是克隆

protected native Object clone() throws CloneNotSupportedException;

• 原型表明了有一个样板实例，这个原型是可定制的。原型模式多用于创建复杂的或者构造耗时的实例，因为这种情况下，复制一个已经存在的实例可使程序运行更高效。
• 应用场景
  1. 类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。这时我们就可以通过原型拷贝避免这些消耗。
  2. 通过new产生的一个对象需要非常繁琐的数据准备或者权限，这时可以使用原型模式。
  3. 一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用，即保护性拷贝。
• 使用方式
  1. 实现Cloneable接口。在java语言有一个Cloneable接口，它的作用只有一个，就是在运行时通知虚拟机可以安全地在实现了此接口的类上使用clone方法。在java虚拟机中，只有实现了这个接口的类才可以被拷贝，否则在运行时会抛出CloneNotSupportedException异常。
  2. 重写Object类中的clone方法。Java中，所有类的父类都是Object类，Object类中有一个clone方 法，作用是返回对象的一个拷贝，但是其作用域protected类型的，一般的类无法调用，因此 Prototype类需要将clone方法的作用域修改为public类型。
• 原型模式分为浅复制和深复制
  • 浅复制：只是拷贝了基本类型的数据，而引用类型数据，只是拷贝了一份引用地址。
  • 深复制：在计算机中开辟了一块新的内存地址用于存放复制的对象。

建造者模式（构建与表示分离、StringBuilder）

• 是将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的方式进行创建。
• 工厂类模式是提供的是创建单个类的产品，而建造者模式则是将各种产品集中起来进行管理，用来具有不同的属性的产品
• 建造者模式通常包括下面几个角色:
  1. uilder：给出一个抽象接口，以规范产品对象的各个组成成分的建造。这个接口规定要实现复杂对象的哪些部分的创建，并不涉及具体的对象部件的创建。
  2. ConcreteBuilder：实现Builder接口，针对不同的商业逻辑，具体化复杂对象的各部分的创建。 在建造过程完成后，提供产品的实例。
  3. Director：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。
  4. Product：要创建的复杂对象。
• 使用场景
  1. 需要生成的对象具有复杂的内部结构。
  2. 需要生成的对象内部属性本身相互依赖。
     • 与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。
     • JAVA 中的 StringBuilder就是建造者模式创建的，他把一个单个字符的char数组组合起来
     • Spring不是建造者模式，它提供的操作应该是对于字符串本身的一些操作，而不是创建或改变一个字符串。

// lombok
@Builder
class User {
    private String  name;
    private String password;
    private String nickName;
    private int age;
}


public class APP {
    public static void main(String[] args) {
        User d = User.builder()
                .name("foo")
                .password("pAss12345")
                .age(25)
                .build();
      	// 链式
      	User user = new User().setName("").setPassword("").setAge(20);
    }
}

代理模式（AOP、异常处理）

• 通过代理控制对象的访问，可以在这个对象调用方法之前、调用方法之后去处理/添加新的功能。 (也就是AOP微实现)。代理在原有代码乃至原业务流程都不修改的情况下，直接在业务流程中切入新代码，增加新功能， 这也和Spring的(面向切面编程)很相似
• 用一个代理来隐藏具体实现类的实现细节，通常还用于在真实的实现的前后添加一部分逻辑。既然说是代理，那就要对客户端隐藏真实实现，由代理来负责客户端的所有请求。当然，代理只是个代理，它不会完成实际的业务逻辑，而是一层皮而已，但是对于客户端来说，它必须表现得就是客户端需要的真实实现。
• 应用场景
  • Spring AOP、日志打印、异常处理、事务控制、权限控制等
• 分类
  • 静态代理(静态定义代理类)
    • 简单代理模式，是动态代理的理论基础。常见使用在代理模式。由程序员创建或工具生成代理类的源码，再编译代理类。所谓静态也就是在程序运行前就已经存在代理类的字节码文件，代理类和委托类的关系在运行前就确定了。
    • 缺点：每个需要代理的对象都需要自己重复编写代理，很不舒服，
    • 优点：但是可以面相实际对象或者是接口的方式实现代理
  • 动态代理(动态生成代理类，也称为Jdk自带动态代理)
    • 使用反射完成代理。需要有顶层接口才能使用，常见是mybatis的mapper文件是代理。动态代理的对象，是利用JDK的API，动态的在内存中构建代理对象(是根据被代理的接口来动态生成代理类的class文件，并加载运行的过程)，这就叫动态代理
    • 缺点：必须是面向接口，目标业务类必须实现接口
    • 优点：不用关心代理类，只需要在运行阶段才指定代理哪一个对象
  • Cglib 、javaassist(字节码操作库)
    • 也是使用反射完成代理，可以直接代理类(jdk动态代理不行)，使用字节码技术，不能对final类进行继承。(需要导入jar包)

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

public class FoodServiceImpl implements FoodService {
    public Food makeChicken() {
        Food f = new Chicken()
        f.setChicken("1kg");
        f.setSpicy("1g");
        f.setSalt("3g");
        return f;
    }
    public Food makeNoodle() {
        Food f = new Noodle();
        f.setNoodle("500g");
        f.setSalt("5g");
        return f;
    }
}

// 代理要表现得“就像是”真实实现类，所以需要实现 FoodService
public class FoodServiceProxy implements FoodService {
    // 内部一定要有一个真实的实现类，当然也可以通过构造方法注入
    private FoodService foodService = new FoodServiceImpl();

    public Food makeChicken() {
        System.out.println("我们马上要开始制作鸡肉了");
        // 如果我们定义这句为核心代码的话，那么，核心代码是真实实现类做的，
        // 代理只是在核心代码前后做些“无足轻重”的事情
        Food food = foodService.makeChicken();
        System.out.println("鸡肉制作完成啦，加点胡椒粉"); // 增强
        food.addCondiment("pepper");
        return food;
    }
    public Food makeNoodle() {
        System.out.println("准备制作拉面~");
        Food food = foodService.makeNoodle();
        System.out.println("制作完成啦")
        return food;
    }
}

// 用代理来实例化接口
FoodService foodService = new FoodServiceProxy();
foodService.makeChicken();

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

说到动态代理，又可以展开说，Spring 中实现动态代理有两种：

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

适配器模式

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

适配器模式总体来说分三种：默认适配器模式、对象适配器模式、类适配器模式。

默认适配器模式

我们用 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);
}

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

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

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

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

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

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

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

对象适配器模式

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

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

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

public class WildCock implements Cock {
    public void gobble() {
        System.out.println("咕咕叫");
    }
    public void fly() {
        System.out.println("鸡也会飞哦");
    }
}

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

// 毫无疑问，首先，这个适配器肯定需要 implements Duck，这样才能当做鸭来用
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 static void main(String[] args) {
    // 有一只野鸡
      Cock wildCock = new WildCock();
      // 成功将野鸡适配成鸭
      Duck duck = new CockAdapter(wildCock);
      ...
}

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

类适配器模式

适配器模式总结

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

   一个采用继承，一个采用组合；

   类适配属于静态实现，对象适配属于组合的动态实现，对象适配需要多实例化一个对象。

   总体来说，对象适配用得比较多。

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

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

桥梁模式

理解桥梁模式，其实就是理解代码抽象和解耦。我们首先需要一个桥梁，它是一个接口，定义提供的接口方法。

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

然后是一系列实现类：

public class RedPen implements DrawAPI {
    @Override
    public void draw(int radius, int x, int y) {
        System.out.println("用红色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
    }
}
public class GreenPen implements DrawAPI {
    @Override
    public void draw(int radius, int x, int y) {
        System.out.println("用绿色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
    }
}
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：

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

定义抽象类的子类：

// 圆形
public class Circle extends Shape {
    private int radius;
    public Circle(int radius, DrawAPI drawAPI) {
        super(drawAPI);
        this.radius = radius;
    }
    public void draw() {
        drawAPI.draw(radius, 0, 0);
    }
}
// 长方形
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;
    }
    public void draw() {
        drawAPI.draw(0, x, y);
    }
}

最后，我们来看客户端演示：

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();
}

桥梁模式的优点也是显而易见的，就是非常容易进行扩展。

装饰模式

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

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

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

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

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

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

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

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

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

不说废话了，上代码。

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

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

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

public class BlackTea extends Beverage {
      public String getDescription() {
        return "红茶";
    }
      public double cost() {
        return 10;
    }
}
public class GreenTea extends Beverage {
    public String getDescription() {
        return "绿茶";
    }
      public double cost() {
        return 11;
    }
}
...// 咖啡省略

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

// 调料
public abstract class Condiment extends Beverage {}

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

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

public class Mango extends Condiment {
    private Beverage bevarage;
    public Mango(Beverage bevarage) {
        this.bevarage = bevarage;
    }
    public String getDescription() {
        return bevarage.getDescription() + ", 加芒果";
    }
    public double cost() {
        return beverage.cost() + 3; // 加芒果需要 3 元
    }
}
...// 给每一种调料都加一个类

看客户端调用：

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

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

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

Beverage beverage = new Mongo(new Pearl(new Lemon(new Lemon(new BlackTea()))));

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

下面，我们再来说说 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("")));

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

门面模式（外观模式，接口）

• 隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口
• 它向现有的系统添加一个接口，用这一个接口来隐藏实际的系统的复杂性。
• 使用外观模式，他外部看起来就是一个接口，其实他的内部有很多复杂的接口已经被实现

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

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

public interface Shape {
   void draw();
}

定义几个实现类：

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

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

客户端调用：

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 static void main(String[] args) {
  ShapeMaker shapeMaker = new ShapeMaker();

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

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

组合模式

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

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

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

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

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

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

   public List getSubordinates(){
     return subordinates;
   }

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

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

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

享元模式

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

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

模板方法模式

• 定义一个操作中的算法骨架(父类)，而将一些步骤延迟到子类中。 模板方法使得子类可以不改变一个算法的结构来重定义该算法的

• 什么时候使用模板方法

  实现一些操作时，整体步骤很固定，但是呢。就是其中一小部分需要改变，这时候可以使用模板方法模式，将容易变的部分抽象出来，供子类实现。

• 应用场景：数据库访问的封装、Junit单元测试、servlet中关于doGet/doPost方法的调用等等

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

通常会有一个抽象类：

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 {
    public void apply() {
        System.out.println("子类实现抽象方法 apply");
    }

    public void end() {
        System.out.println("我们可以把 method3 当做钩子方法来使用，需要的时候覆写就可以了");
    }
}

客户端调用演示：

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

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

策略模式（if…else）

• 定义了一系列的算法或逻辑或相同意义的操作，并将每一个算法、逻辑、操作封装起来，而且使它们还可以相互替换。(其实策略模式Java中用的非常非常广泛)

• 我觉得主要是为了简化 if…else 所带来的复杂和难以维护。

• 应用场景

  • 策略模式的用意是针对一组算法或逻辑，将每一个算法或逻辑封装到具有共同接口的独立的类中， 从而使得它们之间可以相互替换。
  • 例如：我要做一个不同会员打折力度不同的三种策略，初级会员，中级会员，高级会员(三种不同的计算)。
  • 例如：我要一个支付模块，我要有微信支付、支付宝支付、银联支付等

• 优点

  • 算法可以自由切换。 避免使用多重条件判断。扩展性非常良好。

• 缺点

  • 策略类会增多。 所有策略类都需要对外暴露。

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

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

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

public class RedPen implements Strategy {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用红色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class GreenPen implements Strategy {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用绿色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
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 int executeDraw(int radius, int x, int y){
      return strategy.draw(radius, x, y);
   }
}

客户端演示：

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

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

观察者模式（发布订阅）

• 行为性模型，行为型模式关注的是系统中对象之间的相互交互，解决系统在运行时对象之间的相互通信和协作，进一步明确对象的职责。

• 观察者模式，是一种行为性模型，又叫发布-订阅模式，他定义对象之间一种一对多的依赖关系， 使得当一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。

• 模式的职责

  观察者模式主要用于1对N的通知。当一个对象的状态变化时，他需要及时告知一系列对象，令他们做出相应。

• 实现有两种方式

  1. 推：每次都会把通知以广播的方式发送给所有观察者，所有的观察者只能被动接收。
  2. 拉：观察者只要知道有情况即可，至于什么时候获取内容，获取什么内容，都可以自主决定。

• 应用场景

  • 关联行为场景，需要注意的是，关联行为是可拆分的，而不是“组合”关系。事件多级触发场景。
  • 跨系统的消息交换场景，如消息队列、事件总线的处理机制。

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

public class Subject {
    private List observers = new ArrayList();
    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();
        }
    }
}

定义观察者接口：

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

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

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

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

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

客户端使用也非常简单：

public static void main(String[] args) {
    // 先定义一个主题
    Subject subject1 = new Subject();
    // 定义观察者
    new BinaryObserver(subject1);
    new HexaObserver(subject1);

    // 模拟数据变更，这个时候，观察者们的 update 方法将会被调用
    subject.setState(11);
}

output:

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

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

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

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

责任链模式

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

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

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

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

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;
    }
}

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

校验用户是否是新用户：

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

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

public class LocationRuleHandler extends RuleHandler {
    public void apply(Context context) {
        boolean allowed = activityService.isSupportedLocation(context.getLocation);
        if (allowed) {
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(context);
            }
        } else {
            throw new RuntimeException("非常抱歉，您所在的地区无法参与本次活动");
        }
    }
}

校验奖品是否已领完：

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

客户端：

public static void main(String[] args) {
    RuleHandler newUserHandler = new NewUserRuleHandler();
    RuleHandler locationHandler = new LocationRuleHandler();
    RuleHandler limitHandler = new LimitRuleHandler();

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

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

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

状态模式

废话我就不说了，我们说一个简单的例子。商品库存中心有个最基本的需求是减库存和补库存，我们看看怎么用状态模式来写。核心在于，我们的关注点不再是 Context 是该进行哪种操作，而是关注在这个 Context 会有哪些操作。

定义状态接口：

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

定义减库存的状态：

public class DeductState implements State {

    public void doAction(Context context) {
        System.out.println("商品卖出，准备减库存");
        context.setState(this);
        //... 执行减库存的具体操作
    }

    public String toString() {
        return "Deduct State";
    }
} 

定义补库存状态：

public class RevertState implements State {

    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 void getState() {
        return this.state;
    }
}

我们来看下客户端调用，大家就一清二楚了：

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 处于什么状态的。

spring中用到哪些设计模式？

1. 工厂模式，这个很明显，在各种BeanFactory以及ApplicationContext创建中都用到了；
2. 模版模式，这个也很明显，在各种BeanFactory以及ApplicationContext实现中也都用到了；
3. 代理模式，在Aop实现中用到了JDK的动态代理；
4. 单例模式，这个比如在创建bean的时候。
5. 外观模式，Tomcat中有很多场景都使用到了外观模式，因为Tomcat中有很多不同的组件，每个组件需要相互通信，但又不能将自己内部数据过多地暴露给其他组件。用外观模式隔离数据是个很好的方法。
6. 策略模式，因为Comparator这个接口简直就是为策略模式而生的。Comparable和Comparator的区别一文中，详细讲了Comparator的使用。比方说Collections里面有一个sort方法，因为集合里面的元素有可能是复合对象，复合对象并不像基本数据类型，可以根据大小排序，复合对象怎么排序呢？基于这个问题考虑，Java要求如果定义的复合对象要有排序的功能，就自行实现Comparable接口或Comparator接口.
7. 原型模式：使用原型模式创建对象比直接new一个对象在性能上好得多，因为Object类的clone()方法是一个native方法，它直接操作内存中的二进制流，特别是复制大对象时，性能的差别非常明显。
8. 迭代器模式：Iterable接口和Iterator接口 这两个都是迭代相关的接口，可以这么认为，实现了Iterable接口，则表示某个对象是可被迭代的；Iterator接口相当于是一个迭代器，实现了Iterator接口，等于具体定义了这个可被迭代的对象时如何进行迭代的