概述

设计模式是针对软件开发中经常遇到的一些设计问题，总结出来的一套解决方案或者设计思路。

大部分设计模式要解决的都是代码的可扩展性问题。

对于灵活多变的业务，需要用到设计模式，提升扩展性和可维护性，让代码能适应更多的变化;

设计模式的核心就是，封装变化，隔离可变性

设计模式解决的问题:

创建型设计模式主要解决“对象的创建”问题，创建和使用代码解耦;
结构型设计模式主要解决“类或对象的组合或组装”问题，将不同功能代码解耦;
行为型设计模式主要解决的就是“类或对象之间的交互”问题。将不同的行为代码解耦，具体到观察者模式，它是将观察者和被观察者代码解耦。

设计模式关注重点: 了解它们都能解决哪些问题，掌握典型的应用场景，并且懂得不过度应用。

经典的设计模式有 23 种。随着编程语言的演进，一些设计模式（比如 Singleton）也随之过时，甚至成了反模式，一些则被内置在编程语言中（比如 Iterator），另外还有一些新的模式诞生（比如 Monostate）。

创建型模式主要解决类或对象的组合或组装问题，是从程序的结构上实现松耦合，从而可以扩大整体的类结构，用来解决更大的问题。

结构型设计模式是一组用于解决对象和类之间的组织关系、复杂性和交互问题的设计模式。它们主要关注如何通过类和对象的组合来形成更大的结构，并提供了灵活的方式来实现系统的组件之间的通信和协作。结构型设计模式主要解决以下问题：

对象之间的接口和实现分离：结构型设计模式可以帮助将抽象与实现分离，使得对象之间的接口更加清晰和可扩展。例如，适配器模式可以将不兼容的接口转换为统一的接口，使得不同类之间的交互更加简单。
类之间的关系管理：结构型设计模式提供了一种有效的方式来管理类之间的关系，以确保系统的灵活性和可维护性。例如，装饰器模式允许在运行时动态地为对象添加功能，而不必修改原始类的结构。
对象的组合和组件化：结构型设计模式通过对象的组合和组件化，能够更好地处理系统中的复杂性。例如，组合模式允许将对象组织成树状结构，形成部分-整体的层次结构，以便更容易地处理对象集合。
对象的访问和控制：结构型设计模式提供了一些机制来控制对象的访问和可见性，以及限制对象之间的依赖关系。例如，外观模式可以封装一组复杂子系统的接口，提供简化的接口给客户端使用。
类和对象的灵活性：结构型设计模式通过将类和对象组合起来，提供了更大的灵活性和可扩展性。例如，桥接模式可以将抽象与实现解耦，使得它们可以独立地变化和演化。

结构型设计模式主要关注对象和类之间的组织关系、复杂性和交互问题。它们通过提供灵活的方式来管理对象之间的接口、关系和行为，帮助我们构建更健壮、灵活和可扩展的软件系统。

代理模式：为真实对象提供一个代理，从而控制对真实对象的访问。
适配模式：使原本由于接口不兼容不能一起工作的类可以一起工作。
桥接模式：处理多层继承结构，处理多维度变化的场景，将各个维度设计成独立的继承结构，使各个维度可以独立的扩展在抽象层建立关联。
组合模式：将对象组合成树状结构以表示”部分和整体”层次结构，使得客户可以统一的调用叶子对象和容器对象。
装饰模式：动态地给一个对象添加额外的功能，比继承灵活。
外观模式：为子系统提供统一的调用接口，使得子系统更加容易使用。
享元模式：运用共享技术有效的实现管理大量细粒度对象，节省内存，提高效率。

结构型

常用的有：代理模式、桥接模式、装饰者模式、适配器模式。

不常用的有：门面模式、组合模式、享元模式。

代理模式是解耦功能和非功能代码的类组合，代理类和被代理类实现或继承共同的父类；

桥接模式是从不同的纬度独立发展有各自不同的父类抽象，他们可以相互组合实现复杂关系的实现；

装饰器是对功能的增强，装饰器类和原始类有这共同的父类；

实际上，符合“组合关系”这种代码结构的设计模式有很多，比如之前讲过的代理模式、桥接模式，还有现在的装饰器模式。尽管它们的代码结构很相似，但是每种设计模式的意图是不同的。就拿比较相似的代理模式和装饰器模式来说吧，代理模式中，代理类附加的是跟原始类无关的功能，而在装饰器模式中，装饰器类附加的是跟原始类相关的增强功能。

代理、桥接、装饰器、适配器 4 种设计模式的区别：

代理、桥接、装饰器、适配器，这 4 种模式是比较常用的结构型设计模式。它们的代码结构非常相似。笼统来说，它们都可以称为 Wrapper 模式，也就是通过 Wrapper 类二次封装原始类。

尽管代码结构相似，但这 4 种设计模式的用意完全不同，也就是说要解决的问题、应用场景不同，这也是它们的主要区别。这里我就简单说一下它们之间的区别。

代理模式：

代理模式在不改变原始类接口的条件下，为原始类定义一个代理类，主要目的是控制访问，而非加强功能，这是它跟装饰器模式最大的不同。
桥接模式：

桥接模式的目的是将接口部分和实现部分分离，从而让它们可以较为容易、也相对独立地加以改变。
装饰器模式：

装饰者模式在不改变原始类接口的情况下，对原始类功能进行增强，并且支持多个装饰器的嵌套使用。
适配器模式：

适配器模式是一种事后的补救策略。适配器提供跟原始类不同的接口，而代理模式、装饰器模式提供的都是跟原始类相同的接口。

适配器是做接口转换，解决的是原接口和目标接口不匹配的问题。

门面模式做接口整合，解决的是多接口调用带来的问题。

结构型设计模式核心就是代码的组合来达到最大的扩展，不同模式根据解决问题不同，实现方式不同叫不同名字，归根结底都是在一个类中注入另一个类进行组合

代理模式。它在不改变原始类（或者叫被代理类）代码的情况下，通过引入代理类来给原始类附加功能。代理模式在平时的开发经常被用到，常用在业务系统中开发一些非功能性需求，比如：监控、统计、鉴权、限流、事务、幂等、日志。

桥接模式有两种理解方式。第一种理解方式是“将抽象和实现解耦，让它们能独立开发”。这种理解方式比较特别，应用场景也不多。另一种理解方式更加简单，类似“组合优于继承”设计原则，这种理解方式更加通用，应用场景比较多。不管是哪种理解方式，它们的代码结构都是相同的，都是一种类之间的组合关系。

装饰器模式

“组合优于继承”，可以“使用组合来替代继承”。 装饰器模式最本质的特征是将原有类的附加功能抽离出来，简化原有类的逻辑。

装饰类和目标类实现同一接口或者继承同一个类，目标类组合进装饰类，组合可以避免继承结构爆炸

装饰器模式用于功能增强

Java IO 类的设计思想

Java IO 类库非常庞大和复杂，有几十个类，负责 IO 数据的读取和写入。可以从下面两个维度将它划分为四类。具体如下所示：

针对不同的读取和写入场景，Java IO 又在这四个父类基础之上，扩展出了很多子类。具体如下所示：

基于装饰器模式的设计方案

“组合优于继承”，可以“使用组合来替代继承”。

如果我们需要附加更多的增强功能，那就会导致组合爆炸，类继承结构变得无比复杂，代码既不好扩展，也不好维护。对于组合多的情况，继承结构过于复杂，就不应该用继承

下面的代码展示了 Java IO 的这种设计思路：

public abstract class InputStream {
  //...
  public int read(byte b[]) throws IOException {
    return read(b, 0, b.length);
  }
  
  public int read(byte b[], int off, int len) throws IOException {
    //...
  }
  
  public long skip(long n) throws IOException {
    //...
  }

  public int available() throws IOException {
    return 0;
  }
  
  public void close() throws IOException {}

  public synchronized void mark(int readlimit) {}
    
  public synchronized void reset() throws IOException {
    throw new IOException("mark/reset not supported");
  }

  public boolean markSupported() {
    return false;
  }
}

public class BufferedInputStream extends InputStream {
  protected volatile InputStream in;

  protected BufferedInputStream(InputStream in) {
    this.in = in;
  }
  
  //...实现基于缓存的读数据接口...  
}

public class DataInputStream extends InputStream {
  protected volatile InputStream in;

  protected DataInputStream(InputStream in) {
    this.in = in;
  }
  
  //...实现读取基本类型数据的接口
}

从 Java IO 的设计来看，装饰器模式相对于简单的组合关系，还有两个比较特殊的地方。

第一个比较特殊的地方是：装饰器类和原始类继承同样的父类，这样我们可以对原始类“嵌套”多个装饰器类。 比如，下面这样一段代码，我们对 FileInputStream 嵌套了两个装饰器类：BufferedInputStream 和 DataInputStream，让它既支持缓存读取，又支持按照基本数据类型来读取数据。

//BufferedInputStream和DataInputStream继承FileInputStream进行功能增强
InputStream in = new FileInputStream("/user/wangzheng/test.txt");
InputStream bin = new BufferedInputStream(in);
DataInputStream din = new DataInputStream(bin);
int data = din.readInt();

第二个比较特殊的地方是：装饰器类是对功能的增强，这也是装饰器模式应用场景的一个重要特点。 实际上，符合“组合关系”这种代码结构的设计模式有很多，比如之前讲过的代理模式、桥接模式，还有现在的装饰器模式。尽管它们的代码结构很相似，但是每种设计模式的意图是不同的。就拿比较相似的代理模式和装饰器模式来说吧，代理模式中，代理类附加的是跟原始类无关的功能，而在装饰器模式中，装饰器类附加的是跟原始类相关的增强功能。


// 代理模式的代码结构(下面的接口也可以替换成抽象类)
public interface IA {
  void f();
}
public class A impelements IA {
  public void f() { //... }
}
public class AProxy implements IA {
  private IA a;
  public AProxy(IA a) {
    this.a = a;
  }
  
  public void f() {
    // 新添加的代理逻辑
    a.f();
    // 新添加的代理逻辑
  }
}

// 装饰器模式的代码结构(下面的接口也可以替换成抽象类)
public interface IA {
  void f();
}
public class A implements IA {
  public void f() { //... }
}
public class ADecorator implements IA {
  private IA a;
  public ADecorator(IA a) {
    this.a = a;
  }
  
  public void f() {
    // 功能增强代码
    a.f();
    // 功能增强代码
  }
}

实际上，如果去查看 JDK 的源码，你会发现，BufferedInputStream、DataInputStream 并非继承自 InputStream，而是另外一个叫 FilterInputStream 的类。那这又是出于什么样的设计意图，才引入这样一个类呢？

我们再重新来看一下 BufferedInputStream 类的代码。InputStream 是一个抽象类而非接口，而且它的大部分函数（比如 read()、available()）都有默认实现，按理来说，我们只需要在 BufferedInputStream 类中重新实现那些需要增加缓存功能的函数就可以了，其他函数继承 InputStream 的默认实现。但实际上，这样做是行不通的。

对于即便是不需要增加缓存功能的函数来说，BufferedInputStream 还是必须把它重新实现一遍，简单包裹对 InputStream 对象的函数调用。具体的代码示例如下所示。如果不重新实现，那 BufferedInputStream 类就无法将最终读取数据的任务，委托给传递进来的 InputStream 对象来完成。这一部分稍微有点不好理解，你自己多思考一下。

实际上，DataInputStream 也存在跟 BufferedInputStream 同样的问题。为了避免代码重复，Java IO 抽象出了一个装饰器父类 FilterInputStream，代码实现如下所示。InputStream 的所有的装饰器类（BufferedInputStream、DataInputStream）都继承自这个装饰器父类。这样，装饰器类只需要实现它需要增强的方法就可以了，其他方法继承装饰器父类的默认实现。

public class FilterInputStream extends InputStream {
  protected volatile InputStream in;

  protected FilterInputStream(InputStream in) {
    this.in = in;
  }

  public int read() throws IOException {
    return in.read();
  }

  public int read(byte b[]) throws IOException {
    return read(b, 0, b.length);
  }
   
  public int read(byte b[], int off, int len) throws IOException {
    return in.read(b, off, len);
  }

  public long skip(long n) throws IOException {
    return in.skip(n);
  }

  public int available() throws IOException {
    return in.available();
  }

  public void close() throws IOException {
    in.close();
  }

  public synchronized void mark(int readlimit) {
    in.mark(readlimit);
  }

  public synchronized void reset() throws IOException {
    in.reset();
  }

  public boolean markSupported() {
    return in.markSupported();
  }
}

装饰器模式主要解决继承关系过于复杂的问题，通过组合来替代继承。它主要的作用是给原始类添加增强功能。这也是判断是否该用装饰器模式的一个重要的依据。除此之外，装饰器模式还有一个特点，那就是可以对原始类嵌套使用多个装饰器。为了满足这个应用场景，在设计的时候，装饰器类需要跟原始类继承相同的抽象类或者接口。

那对于“添加缓存”这个应用场景来说，我们到底是该用代理模式还是装饰器模式呢？你怎么看待这个问题？

代理模式体现封装性，非业务功能与业务功能分开，而且使用是透明的，使用者只需要关注于自身的业务，在业务场景上适用于对某一类功能进行加强，比如日志，事务，权限。装饰器模式体现多态性，优点在于避免了继承爆炸，适用于扩展多个平行功能。在场景上，这些扩展的功能可以像火车厢一样串起来，使原有的业务功能不断增强。具体到“缓存”这个单个问题，两种模式都可以，主要还是看设计者的目的，如果是为了新增功能的隐藏性，就使用代理模式；如果设计者不仅要增加“缓存”功能，还要增加“过滤”等功能，就更适于装饰器模式。

使用装饰器模式扩展日志格式输出

为了加深印象，我们再来看一个应用场景。需求大致是这样的，系统采用的是SLS服务监控项目日志，以JSON格式解析，因此需要将项目中的日志封装成JSON格式再打印。现有的日志体系采用Log4j + Slf4j框架搭建而成。客户端调用如下。

　　private static final Logger logger = LoggerFactory.getLogger(Component.class);
        logger.error(string);

这样打印出来的是毫无规则的一行行字符串。当考虑将其转换成JSON格式时，笔者采用装饰器模式。目前有的是统一接口Logger和其具体实现类，笔者要加的就是一个装饰类和真正封装成JSON格式的装饰产品类。创建装饰器类DecoratorLogger。

public class DecoratorLogger implements Logger {

    public Logger logger;

    public DecoratorLogger(Logger logger) {

        this.logger = logger;
    }

    public void error(String str) {}

    public void error(String s, Object o) {

    }
    //省略其他默认实现
}

创建具体组件JsonLogger类。

public class JsonLogger extends DecoratorLogger {
    public JsonLogger(Logger logger) {
        super(logger);
    }
        
    @Override
    public void info(String msg) {

        JSONObject result = composeBasicJsonResult();
        result.put("MESSAGE", msg);
        logger.info(result.toString());
    }
    
    @Override
    public void error(String msg) {
        
        JSONObject result = composeBasicJsonResult();
        result.put("MESSAGE", msg);
        logger.error(result.toString());
    }
    
    public void error(Exception e) {

        JSONObject result = composeBasicJsonResult();
        result.put("EXCEPTION", e.getClass().getName());
        String exceptionStackTrace = Arrays.toString(e.getStackTrace());
        result.put("STACKTRACE", exceptionStackTrace);
        logger.error(result.toString());
    }
    
    private JSONObject composeBasicJsonResult() {
        //拼装了一些运行时的信息
        return new JSONObject();
    }
}

可以看到，在JsonLogger中，对于Logger的各种接口，我们都用JsonObject对象进行一层封装。在打印的时候，最终还是调用原生接口logger.error(string)，只是这个String参数已经被装饰过了。如果有额外的需求，则可以再写一个函数去实现。比如error(Exception e)，只传入一个异常对象，这样在调用时就非常方便。另外，为了在新老交替的过程中尽量不改变太多代码和使用方式，笔者又在JsonLogger中加入了一个内部的工厂类JsonLoggerFactory（这个类转移到DecoratorLogger中可能更好一些）。它包含一个静态方法，用于提供对应的JsonLogger实例。最终在新的日志体系中，使用方式如下。

    private static final Logger logger = JsonLoggerFactory.getLogger(Client.class);

    public static void main(String[] args) {

        logger.error("错误信息");
    }

对于客户端而言，唯一与原先不同的地方就是将LoggerFactory改为JsonLoggerFactory即可，这样的实现，也会更快更方便地被其他开发者接受和习惯。最后看如下图所示的类图。

file

结构型设计模式之装饰器模式

概述

装饰器模式

Java IO 类的设计思想

基于装饰器模式的设计方案

使用装饰器模式扩展日志格式输出