25 | 设计模式：每一种都是一个特定问题的解决方案_设计模式的()部分给出了如何解决再现问题-CSDN博客

本文链接：https://blog.csdn.net/qq_37756660/article/details/136674599

今天，我们来聊聊设计模式。作为一个讲软件设计的专栏，不讲设计模式有些说不过去。现在的程序员，基本上在工作了一段时间之后，都会意识到学习设计模式的重要性。

因为随着工作经验的增多，大家会逐渐认识到，代码写不好会造成各种问题，而设计模式则是所有软件设计的知识中，市面上参考资料最多，最容易学习的知识。

但是，你也知道，设计模式的内容很多，多到可以单独地作为一本书或一个专栏的内容。如果我们要在这个专栏的篇幅里，细致地学习设计模式的内容就会显得有些局促。

所以，这一讲，打算谈谈如何理解和学习设计模式，帮助你建立起对设计模式的一个整体认知。

设计模式：一种特定的解决方案

所谓模式，其实就是针对的就是一些普遍存在的问题给出的解决方案。模式这个说法起源于建筑领域，建筑师克里斯托佛·亚历山大曾把建筑中的一些模式汇集成册。结果却是墙里开花墙外香，模式这个说法却在软件行业流行了起来。

最早是 Kent Beck 和 Ward Cunningham 探索将模式这个想法应用于软件开发领域，之后，Erich Gamma 把这一思想写入了其博士论文。而真正让建筑上的模式思想成了设计模式，在软件行业得到了广泛地接受，则是在《设计模式》这本书出版之后了。

这本书扩展了 Erich Gamma 的论文。四位作者 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 也因此名声大噪，得到了 GoF 的称呼。我们今天大部分人知道的 23 种设计模式就是从这本书来的，而困惑也是从这里开始的。

因为，这 23 种设计模式只是在这本书里写的，并不是天底下只有 23 种设计模式。随着人们越发认识到设计模式这件事的重要性，越来越多的模式被发掘了出来，各种模式相关的书先后问世，比如，Martin Fowler 写过《企业应用架构模式》，甚至还有人写了一套 5 卷本的《面向模式的软件架构》。

但是，很多人从开始学习设计模式，就对设计模式的认知产生了偏差，所谓的 23 个模式其实就是 23 个例子。

还记得我们前面几讲学习的设计原则吗？如果用数学来比喻的话，设计原则就像公理，它们是我们讨论各种问题的基础，而设计模式则是定理，它们是在特定场景下，对于经常发生的问题给出的一个可复用的解决方案。

所以，你要想把所有已知的模式统统学一遍，即便不是不可能，也是会花费很多时间的，更何况还会有新的模式不断地出现。而且，虽然《设计模式》那本书上提到的大部分设计模式都很流行，但有一些模式，如果你不是编写特定的代码，你很可能根本就用不上。

比如 Flyweight 模式，如果你的系统中没有那么多小对象，可能就根本用不到它；而 Visitor 模式，在你设计自己系统的时候也很少会用到，因为你自己写的类常常都是可以拿到信息的，犯不上舍近求远。

所以，学习设计模式不要贪多求全，那注定会是一件费力不讨好的事。

想要有效地学习设计模式，首先我们要知道每一个模式都是一个特定的解决方案。关键点在于，我们要知道这个模式在解决什么问题。很多人强行应用设计模式会让代码不必要地复杂起来，原因就在于他在解决的问题，和设计模式本身要解决的问题并不一定匹配。学习设计模式不仅仅要学习代码怎么写，更重要的是要了解模式的应用场景。

从原则到模式

设计模式之所以能成为一个特定的解决方案，很大程度上是因为它是一种好的做法，符合软件设计原则，所以，设计原则其实是这些模式背后的东西。

我们前面花了大量的篇幅在讲各种编程范式、设计原则，因为它们是比设计模式更基础的东西。掌握这些内容，按照它们去写代码，可能你并没有在刻意使用一个设计模式，往往也能写出符合某个设计模式的代码。

举个例子。比如，在用户注册完成之后，相关信息会发给后台的数据汇总模块，以便后面我们进行相关的数据分析。所以，我们会写出这样的代码：

interface UserSender {
  void send(User user);
}

// 把用户信息发送给后台数据汇总模块
class UserCollectorSender implements UserSender {
  private UserCollectorChannel channel;
  
  public void send(final User user) {
    channel.send(user);
  }
}

同时，我们还要把用户注册成功的消息通过短信通知给用户，这里会用到第三方的服务，所以，我们这里要有一个 APP 的 key 和 secret：

// 通过短信发消息
class UserSMSSender implements UserSender {
  private String appKey;
  private String appSecret;
  private UserSMSChannel channel;
  
  public void send(final User user) {
    channel.send(appKey, appSecret, user);
  }
}

现在，我们要对用户的一些信息做处理，保证敏感信息不会泄漏，比如，用户密码。同时，我们还希望信息在发送成功之后，有一个统计，以便我们知道发出了多少的信息。

如果不假思索地加上这段逻辑，那两个类里必然都会有相同的处理，本着单一职责原则，我们把这个处理放到一个父类里面，于是，代码就变成这样：

class BaseUserSender implements UserSender {
  // 敏感信息过滤
  protected User sanitize(final User user) {
    ...
  }
  
  // 收集消息发送信息
  protected void collectMessageSent(final User user) {
    ...
  }
}

class UserCollectorSender extends BaseUserSender {
  ...
  
  public void send(final User user) {
    User sanitizedUser = sanitize(user);
    channel.send(sanitizedUser);
    collectMessageSent(user);
  }
}

class UserSMSSender extends BaseUserSender {
  ...
  
  public void send(final User user) {
    User sanitizedUser = sanitize(user);
    channel.send(appKey, appSecret, user);
    collectMessageSent(user);
  }
}

然而，这两段发送的代码除了发送的部分不一样，其他部分是完全一样的。所以，我们可以考虑把共性的东西提取出来，而差异的部分让子类各自实现：

class BaseUserSender implements UserSender {
  // 发送用户信息
  public void send(final User user) {
    User sanitizedUser = sanitize(user);
    doSend(user);
    collectMessageSent(user);
  }
  
  // 敏感信息过滤
  private User sanitize(final User user) {
    ...
  }
  
  // 收集消息发送信息
  private void collectMessageSent(final User user) {
    ...
  }
}


class UserCollectorSender extends BaseUserSender {
  ...
  
  public void doSend(final User user) {
    channel.send(sanitizedUser);
  }
}


class UserSMSSender extends BaseUserSender {
  ...
  
  public void doSend(final User user) {
    channel.send(appKey, appSecret, user);
  }
}

你是不是觉得这段代码有点眼熟了呢？没错，这就是 Template Method 的设计模式。我们只是遵循着单一职责原则，把重复的代码一点点地消除，结果，我们就得到了一个设计模式。在真实的项目中，你可能很难一眼就看出当前场景是否适合使用某个模式，更实际的做法就是这样遵循着设计原则一点点去调整代码。

其实，只要我们遵循着同样的原则，大多数设计模式都是可以这样一点点推演出来的。所以说，设计模式只是设计原则在特定场景下的应用。

开眼看模式

学习设计模式，我们还应该有一个更开阔的视角。首先是要看到语言的局限，虽然设计模式本身并不局限于语言，但很多模式之所以出现，就是受到了语言本身的限制。

比如，Visitor 模式主要是因为 C++、Java 之类的语言只支持单分发，也就是只能根据一个对象来决定调用哪个方法。而对于支持多分发的语言，Visitor 模式存在的意义就不大了。

Peter Norvig，Google 公司的研究总监，早在 1996 年就曾做过一个分享《动态语言的设计模式》，他在其中也敏锐地指出，设计模式在某种意义上就是为了解决语言自身缺陷的一种权宜之计，其中列举了某些设计模式采用动态语言后的替代方案。

我们还应该知道，随着时代的发展，有一些设计模式本身也在经历变化。比如，Singleton 模式是很多面试官喜爱的一个模式，因为它能考察很多编程的技巧。比如，通过将构造函数私有化，保证不创建出更多的对象、在多线程模式下要进行双重检查锁定（double-check locking）等等。

然而，我在讲可测试性的时候说过，Singleton 并不是一个好的设计模式，它会影响系统的可测试性。从概念上说，系统里只有一个实例和限制系统里只能构建出一个实例，这其实是两件事。

尤其是在 DI 容器普遍使用的今天，DI 容器缺省情况下生成的对象就是只有一个实例。所以，在大部分情况下，我们完全没有必要使用 Singleton 模式。当然，如果你的场景非常特殊，那就另当别论了。

在讲语法和程序库时，我们曾经说过，一些好的做法会逐渐被吸收到程序库，甚至成为语法。设计模式常常就是好做法的来源，所以，一些程序库就把设计模式的工作做了。比如，Observer 模式早在 1.0 版本的时候就进入到 JDK，被监听的对象要继承自 Observable 类就好，用来监听的对象实现一个 Observer 接口就行。

当然，我们讲继承时说过，继承不是一个特别好的选择，Observable 是一个要去继承的类，所以，它做得也并不好。从 Java 9 开始，这个实现就过时（deprecated）了，当然官方的理由会更充分一些，你要是有兴趣可以去了解一下。JDK 中提供的替代方案是PropertyChangeSupport，简言之，用组合替代了继承。

我个人更欣赏的替代方案是 Guava 的EventBus，你甚至都不用实现一个接口，只要用一个 Annotation 标记一下就可以监听了。

Annotation 可以说是消灭设计模式的一个利器。我们刚说过，语言本身的局限造成了一些设计模式的出现，这一点在 Java 上表现得尤其明显。随着 Java 自身的发展，随着 Java 世界的发展，有一些设计模式就越来越少的用到了。比如，Builder 模式通过 Lombok 这个库的一个 Annotation 就可以做到：

@Builder
class Student {
  private String name;
  private int age;
  ...
}

而 Decorator 模式也可以通过 Annotation 实现，比如，一种使用 Decorator 模式的典型场景，是实现事务，很多 Java 程序员熟悉的一种做法就是使用 Spring 的 Transactional，就像下面这样：

class Handler {
  @Transactional
  public void execute() {
    ...
  }
}

随着 Java 8 引入 Lambda，Command 模式的写法也会得到简化，比如写一个文件操作的宏记录器，之前的版本需要声明很多类，类似下面这种：

Macro macro = new Macro();
macro.record(new OpenFile(fileReceiver));
macro.record(new WriteFile(fileReceiver));
macro.record(new CloseFile(fileReceiver));
macro.run();

而有了 Lambda，就可以简化一些，不用为每个命令声明一个类：

Macro macro = new Macro();
macro.record(() -> fileReceiver.openFile());
macro.record(() -> fileReceiver.writeFile());
macro.record(() -> fileReceiver.closeFile());
macro.run();

甚至还可以用 Method Reference 再简化：

Macro macro = new Macro();
macro.record(fileReceiver::openFile);
macro.record(fileReceiver::writeFile);
macro.record(fileReceiver::closeFile);
macro.run();

所以，我们学习设计模式除了学习标准写法的样子，还要知道，随着语言的不断发展，新的写法变成了什么样子。