chenjian723122704的专栏

我们第整个专栏的理论知识点做了串讲，不知道你掌握的如何？对于上节课总结的重点内容，希望你能多花点时间搞透彻，对于一些不那么重要的内容，你可以把它们当做资料，用到的时候随手查询，再深入学习。实际上，虽然理论掌握得差不多，专栏也很贴近实战，每个知识点的讲解都有结合实际的代码案例，并且最后还有集中的项目实战，但落实到自己写代码时，可能还是无法将学习到的理论知识很好的应用。本章，就再聊一聊如何将设计思想、原则、模式等理论知识应用到实际的项目开发中。

单一职责原则的难点在于，对代码职责是否足够单一的判定。这要根据具体的场景来具体分析。同一个类的设计，在不同的场景下，对职责是否单一的判定，可能是不同的。开闭原则是保证代码扩展性的重要指导原则，是对代码扩展性的具体解读。很。

到本章为止，项目实战环节就彻底结束了。在这一部分中，我们通过限流、幂等、灰度这三个实战项目，带你从需求分析、系统设计、代码实现三个环节，学习了如何进行功能性、非功能性需求分析，如何通过合理的设计，完成功能性需求，满足非功能性需求，以及如何编写高质量的代码实现。实际上，项目本身的分析、设计、实现并不重要，不必对细节过于纠结。希望通过这三个例子，分享思考思路、开发套路，让你借鉴并举一反三地应用到你的项目开发中。这才是最有价值的，才是你学习的重点。

本章，我们对比限流框架、幂等框架，讲解了灰度组件的非功能性需求，主要包含易用性、扩展性、灵活性、容错性这样几个方面，并且针对性地解释了对应地设计思路。在易用性方面，我们重点讲解了 “低侵入、松耦合” 的设计思想。限流、幂等框架因为其跟业务无关，可以做到最大程度跟业务解耦，做到低侵入。但是，我们这里实现的代码层面的灰度，因为跟业务强相关，所以，跟业务代码耦合比较紧密，比较难做到低侵入。在扩展性、灵活性方面，除了像限流框架那样，支持各种格式、存储方式的配置方式之外，灰度组件还希望支持复杂的灰度规则。

灰度发布可以分为三个层面的灰度：产品层面的灰度、系统层面的灰度和代码层面的灰度。本章重点讲解代码层面的灰度，通过编程来控制是否执行新的代码逻辑，以及灰度执行新的代码逻辑。代码层面的灰度，主要解决代码质量问题，通过逐渐放量灰度执行，两降低重大代码改动带来的风险。在出问题之后，在不需要修改代码、重新部署、重启系统的情况下，实现快速的回滚。相对于系统层面的灰度，它可以做的更加细粒度，更加灵活、简单、好维护，但也存在着代码侵入的问题，灰度代码跟业务代码耦合在一起。

前面花了两篇文章，用很大的篇幅在讲需求和设计，特别是设计的缘由。而真正到了实现环节，只用了 30 行代码，就实现了幂等框架。这就很好地体现了 “思从深而行从简” 的道理，对于不到 30 行代码，很多人觉得不大可能有啥优化的空间了，但我们今天还是提出了 7 个优化建议，并且对代码结构做了比较大的调整。这说明，只要仔细推敲，再小的代码都有值得优化的地方。大项目和小项目，在编码这个层面，实际上没有太大的区别。再宏达的工程、再庞大的项目，也是一行一行写出来的。

本章讲解了幂等框架的设计思路。在正常情况下，幂等框架的处理流程是比较简单的，调用方生成幂等号，传递给实现方，实现方记录幂等号或者用幂等号判重。但是，幂等框架要处理的异常情况很多，这也是设计幂等框架的复杂之处和难点之处。我们针对三种不同的异常，讲解了幂等框架的应对思路。对于业务代码异常，为了让幂等框架尽可能的灵活，低侵入业务逻辑，发生异常（不管是业务异常还是系统异常），是否允许再重试执行业务逻辑，交给开发这块业务的工程师决定。

本章，我们介绍了幂等框架的一个需求场景，那就是接口超时重试。大部分情况下，如果接口只包含查询、删除、更新这些操作，那接口天然是幂等的。此外，如果接口包含修改操作（插入操作或更新操作），保证接口幂等性就需要做一些额外的工作。现在开源的恭喜很多，但幂等框架非常少见。原因是幂等的保证是业务强相关的。大部分保证幂等性的方式都是针对具体的业务具体处理，比如，利用业务数据中的唯一 ID 唯一性来处理插入操作的幂等性。

这个类是限流算法实现类。它实现了最简单的固定时间窗口限流算法。每个接口都要在内存中对应一个类的代码如下所示。对于代码的逻辑，你可以看上篇文章对固定时间窗口限流算法的讲解。// 200 mstry {// 过了固定时间窗口，要重置计数器和时间统计} else {优秀的代码都是重构出来的，复杂的代码是慢慢堆砌出来的。小步快跑、逐步迭代是我个人比较推崇的开发模式。追求完美主义会让我们迟迟无法下手。所以，为了克服这个问题，一方面，我们可以规划多个小版本来开发；

本章，将框架划分为限流规则、限流算法、限流模式、集成使用这四个模块来分析讲解。除了功能方面的设计外，重点讲解了如何满足易用、灵活、易扩展、低延迟、高容错这些非功能性需求。针对限流，大部分 Java 程序员已经习惯了 Spring 的配置方式。基于最小惊奇原则，在限流框架中，我们也延续 Spring 的配置方式，支持 XML、YAML、Properties 等几种配置文件格式。同时，借鉴 Spring 的约定优于配置设计原则。

本章，我们主要对限流框架做了大的项目背景、需求背景介绍，以及更加具体的需求分析，明确了解要做什么，为下面两篇文章（设计和实现）做准备。本章的讲解中，基本的功能需求其实没有多少，但将非功能性需求考虑进去之后，明显就复杂多了。还是那句老话，写出能用的代码简单，写出好用的代码很难。对于限流框架来说，非功能性需求是设计与实现的难点。怎么做到易用、灵活、可扩展、低延迟、高容错，才是开发的重点。此外，本章还提到了一些需求分析的方法，比如画线框图、写用户用例、测试驱动开发等等。

本章，讲解了 Mybatis 中用到的 8 种设计模式，它们分别是：建造者模式、工程模式、模板模式、解释权模式、单例模式、装饰器模式、适配器模式。再加上上篇文章的职责链模式和动态代理，总共讲了 10 种设计模式。从两篇文章的讲解中，不知道你发现没有，Mybatis 对很多设计模式的实现，都并非标准的代码实现，都做了比较多的自我改进。实际上，这就是所谓的灵活应用，只借鉴不照搬，根据具体问题针对性地去解决。

实际上，Mybatis Plugin 跟 Servlet Filter、Spring Interceptor 的功能是类似的，都是在不修改流程代码的情况下，拦截某些方法调用，在拦截的方法调用后，执行一些额外的代码逻辑。它们的唯一区别在于拦截的位置是不同的。

JDBC 是 Java 访问数据库的开发规范，提供了一套抽象的统一的开发接口，隐藏不同数据库的访问细节。JdbcTemplate、Mybatis、Hibernate 都是对 JDBC 的二次封装，为的是进一步简化数据库开发。其中 JdbcTemplate 不能算得上是 ORM 框架，因为还需要程序员自己编程来实现对象和数据库之间的相互转化。相对于 Hibernate 这种连 SQL 都不用程序员写的全自动 ORM 框架，Mybatis 算式一种半自动化的 ORM 框架。

讲解了 Spring 中支持扩展功能的两种设计模式：观察者模式和模板模式。这两种模式帮助我们创建扩展点，让框架的使用者在不修改源码的情况下，基于扩展点定制化框架功能。实际上，Spring 框架中用到的设计模式非常多，不下十几种。今天就总结罗列下。有些前面已经讲过的或者比较简单的，就点到为止。

本章讲道理 Spring 中用到的两种支持扩展的设计模式：观察者模式和模板模式。其中，观察者模式在 Java、Google Guava、Spring 中都有提供相应的实现代码。在平时的项目开发中，基于这些实现代码，我们可以轻松地实现一个观察者模式。Java 提供的空间比较简单，只包含和两个类。Google Guava 提供的框架功能比较完成和强大，可以通过 EventBus 事件总线来实现观察者模式。

我们常说的 Spring 框架，是指 Spring Framework 基础框架。Spring Framework 是整个 Spring 生态的基石。除了 Spring Framework，Spring 全家桶中还有更多基于 Spring Framework 开发出来的、整合更多功能的框架，比如 Spring Boot、Spring Cloud。在 Spring 全家桶中，Spring Framework 是最基础、最底层的部分。它提供了最基础、最核心的 IOC 和 AOP 功能。

函数式编程的英文是 Functional Programming。那到底什么是函数式编程呢？函数式编程也没有一个严格的官方定义，所以，接下来就从特性上告诉你，什么是函数式编程。严格来讲，函数式编程中的 “函数”，并不是指我们编程语言中的 “函数” 概念，而是指数学 “函数” 或者 “表达式”（比如，y=f(x)。不过，在编程实现时，对于数学 “函数” 或者 “表达式”，一般习惯性地将它们设计成函数。所以，如果不深究的话，函数式编程中的 “函数” 也可以理解为编程语言中的 “函数”。

我通过 Google Guava 这样一个优秀的开源类库，讲解了如何在业务开发中，发现跟业务无关、可以复用的通用功能模块，并将它们抽离出来，设计成独立的类库、框架或功能组件。本章再来学习下，Google Guava 中用到的几中经典的设计模式：Builder 模式、Wrapper 模式，以及之前没有讲过的 Immutable 模式。

Google Guava 是 Google 公司内部 Java 开发工具库的开源版本。Google 内部的很多 Java 项目都在使用它。它提供了一些 JDK 没有提供的功能，以及对 JDK 已有功能的增强功能。

本章，主要讲解了为什么要做 Code Review，Code Review 的价值在哪里。Code Review 践行 “三人行必有我师”能摒弃 “个人英雄主义”能有效提高代码可读性是技术传帮带的有效途径能保证代码不止一个人熟悉能打造良好的技术氛围是一种技术沟通方式能提供团队的自律性此外，还对 Code Review 在落地执行过程中的一些问题，做了简单的问答。希望在你 Code Review 遇到同样的问题时，能对你有所帮助。

实际上，上面刚刚讲的 6 条方法论都没啥新奇的，网上也有很多的信息，最后谁做得好，关键在于执行和细节。有人说，我们做了单元测试、Code Review 了，但到最后，项目还是一堆 bug，代码质量还是很差。这个时候，我们就要去思考一下，单元测试、Code Review 做的到底够不够好，从决策到执行再到考核是否形成了闭环。不能口号喊的 100 分，落实到执行只有 50 分，最后又没有很好的考核机制，好坏大家也都不知道。所以，切忌敏与言而讷与行。此外，刚刚所讲的方法都治标不治本。

本章，我们主要从设计原则和思想的角度，也可以说是设计开发的角度，来学习如何应对复杂软件的开发。主要总结了 7 点。封装与抽象分层与模块化基于接口通信高内聚、松耦合为扩展而设计KISS 首要原则最小惊奇原则（遵守开发规范）当然，这 7 点之间并不是相互独立的，有几点是相互支持的，例如 “高内聚、松耦合” 与抽象封装、分层模块化、基于接口通信。有几点是相互冲突的，比如 KISS 原则与为扩展而设计，这都需要根据实际情况去权衡。

上篇文章和本章主要剖析了 JDK 中应用到的几个设计模式，其中重点剖析的有：工厂模式、建造者模式、装饰器模式、适配器模式、模板模式、观察者模式，此外，我们还汇总了其他模式在 JDK 中的应用，比如：单例模式、享元模式、职责链模式、迭代器模式。实际上，源码都很简单，理解起来不难，都没有逃出我们之前讲解的理论知识范畴。学习的重点也不是表面上去理解、记忆某某类用了哪种设计模式，而是让你了解，在真是的项目开发中，如何灵活应用设计模式，做到活学活用，能够根据具体的场景、需求，做灵活的设计和实现上的调整。

本章重点讲解了工厂模式、建造者模式、装饰器模式和适配器模式，这四种模式在 Java JDK 中的应用，主要目的是给你展示真实项目中是如何灵活应用设计模式的。在本章的讲解中，我们可以学习到，尽管在之前的理论讲解中，都讲到了每个设计模式的经典代码实现，但是，在真实项目中，这些模式的应用更加灵活，代码实现更加自由，可以根据具体的业务场景、功能需求，对代码实现做很大的调整，甚至还可能回对设计模式本身的设计思路做调整。比如，JDK 中的Calendar。

在写代码之前，要多想想未来会有哪些扩展的需求，哪部分是会变的，哪部分是不会变的，这样写会不会导致之后添加新的功能比较困难，代码的可读性好不好等代码质量问题。有了这样的意识，你就里写出高质量的代码不远了。

结构型模式包括：代理模式、桥接模式、装饰器模式、适配器模式、门面模式、组合模式、享元模式。

前面讲观察者模式的时候，我们讲到观察者模式的实现方式有很多种。虽然经典的实现方式没法彻底解耦观察者和被观察者，观察者需要注册到被观察者中，被观察者状态更新需要调用观察者的update()方法。但是在跨进程的实现方式中，我们可以利用消息队列实现彻底解耦，观察者和被观察者都只需要跟消息队列交互，观察者完全不知道被观察者的存在，被观察者也完全不知道观察者的存在。本章提到，中介模式也就为了解耦对象之间的交互，所有的参与者都只与中介进行交互。

解释器模式，为某个语言定义它的语法表示，并定义一个解释器用来处理这个语法。实际上，这里的 “语言” 不仅仅指我们平时说的 中、英、法等各种语言。从广义上讲，只要是能承载信息的载体，都可以称之为 “语言”，比如，古代的结绳记事、盲文、哑语、摩斯密码等。要想了解 “语言” 要表达的信息，就必须定义相应的语法规则。这样，书写者就可以根据语法规则来书写 “句子”，阅读者根据语法规则来阅读 “句子”，这样才能做到信息的正确传递。而我们要讲解的解释器模式，其实就是用来实现根据语法规则解读 “句子” 的解释器。

命令模式在平时开发中并不常用，你稍微了解即可。落实到编码实现，命令模式用到最核心的实现手段，就是将函数封装成对象。我们知道，在大部分编程语言中，函数是没法作为参数传递给其他函数的，也没法赋值给变量。借助命令模式，我们将函数封装成对象，这样就可以实现把函数像对象一样使用。命令模式的主要作用和应用场景，是用来控制命令的执行，比如异步、延迟、排队执行命令、撤销重做命令、存储命令、给命令记录日志等等，这才是命令模式能发挥独一无二作用的地方。

备忘录模式也叫快照模式。具体来说，就是在不违背封装原则的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便之后恢复对象为先前的状态。这个模式的定义表达了两部分内容：一部分是，存储副本以便后期恢复；另一部分是，要在不违背封装原则的前提下，进行对象的备份和恢复。备忘录模式的应用场景也比较明确和有效，主要是用来防丢失、撤销、恢复等。它跟平时我们说的 “备份” 很相似。两者的主要区别在于，备忘录模式更侧重于代码的设计和实现，“备份” 更侧重架构设计或产品设计。

总体来说，访问者模式难以理解，应用场景有限，不是特别必需，不建议在项目中使用它。所以，对于上篇文章的处理资源文件的例子，更推荐使用工厂设计模式来设计和实现。本章重点讲解了 Double Dispatch。在面向对象编程语言中，方法调用可以理解为一种消息传递（Dispatch）。一个对象调用另一个对象的方法，就相当于给它发送一条消息，这条消息起码要包含对象名、方法名和方法参数。所谓 Signle Dispatch，指的是执行哪个对象的方法，根据对象的运行时类型来决定；

访问者模式，允许一个或者多个操作应用到一组对象上，设计意图是解耦操作与对象本身，保持类职责单一、满足开闭原则以及应对代码的复杂性。对于访问者模式，学习的主要难点在代码实现。而代码实现比较复杂的原因是，函数重载在大部分面向对象编程语言重是静态绑定的。也就是说，调用类的哪个重载函数，是在编译期间，由参数声明类型决定的，而非运行时，根据参数的实际类型决定的。正是因为代码实现难理解，所以，在项目中应用这种设计模式，会导致代码的可读性比较差。如果其他人不了解这种设计模式，可能会读不懂、维护不了你写的代码。所以，

前两篇文章，学习了迭代器模式的原理、实现，并分析了在遍历集合的同时增删元素集合，产生不可预期结果的原因及应对策略。本章，再来看这样一个问题： 如何实现一个支持 “快照” 功能的迭代器？这个问题算是上一篇文章内容的延升思考，为的是帮助你加深对迭代器模式的理解。

在通过迭代器来遍历集合元素的同时增删元素，可能会导致某个元素被重复遍历或遍历不到。不过，并不是所有的情况下都会遍历出错，有时候也能正常遍历，所以，这种行为成为不可预期行为或未决行为。实际上，“不可预期” 比直接出错更加可怕，一些隐藏很深、很难 debug 的 bug 就是这么产生的。有两种解决方案，来避免出现这种不可预期的运行结果。一种是遍历时，不允许增删元素。另一种是增删元素之后，遍历报错。第一种实现方式比较难实现，因为很难确定迭代器使用结束的时间点。第二种解决方案更加合理。

迭代器模式，也叫游标模式。它用来遍历集合对象。这里说的 “集合对象”，也叫做 “容器” “聚合对象”，实际上就是包含一组对象的对象，比如数组、链表、树、图、跳表。一个完整的迭代器模式，会设计容器和容器迭代器两部分。为了达到基于接口而非实现编程的目的，容器又包含容器接口、容器实现类，迭代器又包含迭代器接口和迭代器实现类。容器中需要定义iterator()方法，用来创建迭代器。迭代器接口中需要定义hasNext()next()三个最基本的方法。容器对象通过依赖注入传递到迭代器类中。

有限状态机，英文翻译是 Finite State Machine，缩写为 FSM，简称状态机。状态机有三个组成部分：状态（State）、事件（Event）、动作（Action）。事件也称为转移条件（Transaction Condition）。事件触发状态的转移及动作的执行。不过，动作不是必须得，也可能只转移状态，不执行任何动作。对于刚刚给出的状态机定义，结合一个具体的例子进行解释。“超级马里奥” 游戏不知道你玩过没有？

职责链模式常用在空间开发中，用来实现矿机的过滤器、拦截器功能，让框架的使用者在不需要修改框架源码的情况下，添加新的过滤拦截功能。这也体现了之前讲到的对扩展开发、对修改关闭的设计原则。本章，通过 Servlet Filter、Spring Interceptor 两个实际的例子，给你展示了在框架开发中职责链模式具体是怎么应用的。从源码中，可以发现，尽管《6.责任链模式（上）：原理与实现》给出了代码实现，但在实际的开发中，还是要具体问题具体对待，代码实现胡已根据不同的需求有所变化。

在职责链模式中，多个处理器依次处理同一个请求。一个请求先经过 A 处理器处理，然后再把请求传递给 B 处理器，B 处理器处理完后再传递给 C 处理器，以此类推，形成一个链条。链条上的每个处理器各自承担各自的处理职责，所以叫做职责链模式。在 GoF 的定义中，一旦某个处理器能处理这个请求，就不会继续将请求传递给后续的处理器了。当然，在实际的开发中，也存在对这个模式的变体，那就是请求不会中途终止船体，而是会被所有的处理器都处理一遍。职责链模式有两种常用的实现。

一提到 if-else 分支判断，有人就觉得那是烂代码。如果 if-else 分支判断不复杂、代码不多，这其实并没有问题，毕竟 if-else 分支判断几乎是所有编程语言都会提供的语法，存在即有理由。遵循 KISS 原则，怎么简单怎么来，就是最好的设计。非得用策略模式，搞出 n 多个类，反倒是一个过渡设计。一提到策略模式，有人就觉得，它的作用是避免 if-else 分支判断逻辑。实际上，这种认识很片面。策略模式的主要作用还是解耦策略的定义、创建、使用，让每个部分的代码都不至于过于复杂、代码量过多。