我乐了的博客

在实际的软件开发中，责任链模式的应用非常广泛，可以说只要是与流程相关的软件系统都能够使用责任链模式来构建，一方面可以用在代码中实现松散耦合，另一方面可以动态增删子处理流程。责任链模式的原理和实现虽然都非常简单，但是在实际使用中还需要注意维护上下文关系的正确性，一旦出现循环调用，很容易死锁而导致程序崩溃。另外，要注意控制责任链中的处理对象数量。如果处理对象的数量过多，比如超过 20 个，容易让代码变得难以维护，这时还是应该尽可能减少处理对象的数量，将其合并到相类似的处理对象中去。

命令模式将一个或一组命令封装为一个对象，从而能够将函数方法作为参数进行传输，同时还能够解耦客户端和服务端的直接耦合，适用场景有：做简单的请求排队，记录请求日志，以及支持可撤销的操作。简单来说，命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分离开。命令模式的原理稍微有点复杂，在使用时也容易区分不开接收者和命令，好在适用的场景比较有限，对于大多数开发人员来说，并不是高频使用的模式。

在实际的业务开发中，解释器模式很少使用，主要应用于 SQL 解析、符号处理引擎等场景中。在解释器模式中通常会使用树的结构，有点类似于组合模式中定义的树结构，终端表达式对象是叶对象，非终端表达式是组合对象。虽然解释器模式很灵活，能够使用语法规则解析很多复杂的句子，比如，编程语法。但是稍不留神就很容易把解释逻辑写在一个类中，进而导致后期难以维护。除此之外，把解析逻辑拆分为单个的子节点后，又会因为类数量的暴增，导致代码的理解难度倍增。

迭代器模式的实现原理非常简单，关键思想是将访问和遍历的职责从集合对象中分离出来，放入标准的协议对象中。这样既能对客户端隐藏复杂结构的遍历访问方式，也能提供减少重复遍历的代码实现。现在几乎所有编程语言都会实现迭代器模式，主要被实现为类库来使用，可以说使用非常普遍。其实，除了编程语言之外，很多组件也有应用，比如 Redis 中的 rehash() 操作，就是迭代器模式的体现，而且 Redis 更进一步地还区分了安全迭代器和非安全迭代器。

虽然中介者模式的原理和实现都非常简单，但是中介者在系统中承担的责任却是非常重要的。中介者通常会承担两方面的职责。一方面是中转作用（结构性）。不同对象通过中介者进行中转就意味着不再需要显式直接引用对象，比如聊天中的两个用户。当用户需要和另一个对象进行通信时，只需要通过中介者，而不需要直接和对方建立联系。这样从结构上不再会形成网状结构，而是以某个中介者为中心的星型结构，这样能极大地降低对象的结构耦合性。另一方面是协调作用（行为性）。中介者会在自身内部分装协调逻辑，并对同类型的对象请求进行统一的处理。

备忘录模式也叫快照模式，具体来说，就是通过捕获对象在某一个时刻的对象状态，再将其保存到外部对象，以便在需要的时候恢复对象到指定时刻下的状态。备忘录模式的应用场景比较局限，主要是用来备份、撤销、恢复等，这与平时我们常说的“备份”看上去很相似，但实际上两者的差异是很大的：备忘录模式更侧重于代码的设计和实现，支持简单场景中的应用，比如记录 Web 请求中的 header 信息等；而备份更多是以解决方案的形式出现，比如异地容灾备份、数据库主从备份等所支持的是更复杂的业务场景，备份的数据量往往也更大。

虽然观察者模式在原理上是一个比较抽象的模式，但是业界根据不同的应用场景和需求总结出了很多不同的实现方式，这让观察者模式变得易于使用。在观察者模式中，被观察者通常会维护一个观察者列表。当被观察者的状态发生改变时，就会通知观察者。观察者模式现在被大量应用在分布式系统的开发中。从本质上来讲，观察者模式描述了如何建立对象与对象之间一种简单的依赖关系。在现实中，最为常见的观察者模式的例子就是订阅微信公众号，当公众号发布一篇新文章时，我们能在微信上收到消息，然后选择合适的时间打开阅读。

状态模式描述了对象状态的变化以及对象如何在每一种状态下表现出不同的行为。其适合场景是：对象本身具备很多状态变化，同时不同变化需要不同的行为来处理。状态模式虽然可以让我们的代码条理清楚，容易阅读，但是实际上对开闭原则的支持并不友好，新增状态可能会影响原有的状态，在使用时要注意。要想用好状态模式，关键点在于寻找好的状态以及状态与状态之间的关系，而不是急着去实现状态模式。状态确定好以后，状态模式本身的代码实现其实是非常容易的。

策略模式最大的用处是能在运行时改变代码的算法行为，同时给使用者提供一种可以根据情况来选择算法的途径。虽然策略模式是一个比较容易理解和使用的设计模式，但是却增加了使用者的难度，因为你可能需要在了解了所有的策略后才能做出决策。即便是类似排序这样简单的算法，不同使用者的选择也可能完全不同，如果交给使用者来选择，就意味着使用者需要了解不同排序算法的优劣，才能更好地做出选择。不过，策略模式对算法起到了很好的封装作用，通过使用算法和创建算法的分离，将算法实现的复杂性放到了子类去解决。

从上面的分析中，我们能看出，模板方法模式封装了三个变化：算法具体的实现步骤；每一个步骤的具体执行逻辑；实现步骤的数量。模板方法模式是一个比较常用的结构型设计模式，它能帮助我们快速构建一个通用模板，对于固定流程、通用协议而言，模板方法模式都是一个很好的选择。虽然模板方法模式简单实用有很多优势，但是劣势同样明显。比如，继承的结构容易带来“修改一个类而影响所有类”的情况，另外，阅读代码的体验也不是很好，经常需要各个类之间不断切换，并且要想搞清楚整个算法完整的逻辑，可能需要阅读所有子类和父类的代码逻辑。

访问者模式能够通过添加新的行为来封装不同类型的对象，并隐藏不同对象各自的变化。这里所说的隐藏的变化主要包括：允许添加新行为到一组对象里；行为的实现和数量；在运行时动态给对象添加额外行为；访问者类和访问角色类之间的调用关系。

这里我们总结一下代理模式试图解决的问题：无法直接调用某些对象；耗时的操作；某个接口可能需要外部额外操作，如日志记录、权限管控、重复操作等；一直保存大对象；需要控制访问权限。对于这些问题，代理模式通过建立一个代理对象，在原始对象的外围来封装这些问题可能引起的代码变化。代理模式的原理虽然简单，但是应用却非常广泛，特别是在中间件领域随处可见代理模式，比如 Dubbo、gRPC 都是代理模式的优秀实践。到此，我们就学习完结构型模式的所有内容了，现在我们来回顾和总结下结构型模式的相关内容。适配器模式。

享元模式为共享对象定义了一个很好的结构范例。不过，用好享元模式的关键在于找到不可变对象，比如，常用数字、字符等。之所以做对象共享而不是对象复制的一个很重要的原因，就在于节省对象占用的内存空间大小。享元模式强调的是空间效率，比如，一个很大的数据模型对象如何尽量少占用内存并提供可复用的能力；而缓存模式强调的是时间效率，比如，缓存秒杀的活动数据和库存数据等，数据可能会占用很多内存和磁盘空间，但是得保证在大促活动开始时要能及时响应用户的购买需求。也就是说，两者本质上解决的问题类型是不同的。

门面模式的本质是：简化调用，统一操作。门面模式最典型的一种应用就是 API 网关，这个你可能已经非常熟悉了，特别是随着微服务的不断流行，API 网关充当着越来越重要的角色。API 网关要解决的一个主要问题就是：高可用性。但实际上你会发现，从模式的原理上很难解决高可用的问题，因为只要依赖的系统越多，网关出现了问题，那么所有系统都变成了不可用状态。这也是有时不使用 API 网关的原因。现在更多的是通过其他手段来保护网关，比如，降级、限流、熔断等操作，或者通过不断扩展网关的吞吐量处理能力来提高网关的可用性。

装饰模式就像是我们送人礼物时的“包装盒”，我们可以选择各种各样的包装盒，还可以在包装盒里嵌套包装盒。装饰模式在结构上体现为链式结构，通过在外层不断地添加具体装饰器类来对原有的组件类进行扩展，这样在保证原有功能的情况下，还能额外附加新的功能。这也是学习和理解装饰模式的核心所在。虽然装饰模式的原理和使用都很简单，但是有时链式结构本身会让代码调用链条变得很长，变成了一种对原有组件接口的定制化开发。因此，一般情况下不建议装饰器超过 10 个，如果超过还是要考虑重构组件功能。除此之外，

在我看来，组合模式虽然不太常用，但却是非常重要的模式之一，对于初学者来说，可能就需要花比一般模式稍微多一点的时间来理解才行。组合模式的原理很简单，可使用时也可能会因为遍历算法多种多样，反而没看上去那么用好，比如，二叉树、B+ 树等树形结构的遍历算法。

桥接模式可以说是 DIP 原则的具体实践。在软件开发中，一个对象可以从实体和行为两个角度来进行分离，其实就是将依赖从一个大而全的对象变换到依赖两个可以独立变化的维度，控制也就发生了反转。桥接模式因为重视组合和聚合，从而有效避免了多重继承带来的问题。也就是说，通过抽象实体与抽象行为的关联，将静态的继承关系转换为了动态的组合关系，从而使得系统结构更加灵活。

一般来说，适配器模式能够让一个接口与新的接口实现兼容，从而在新的抽象逻辑层次上统一多个不同的接口。但也正是因为适配器模式太过于灵活了，容易导致过度滥用而造成对象间耦合性过高，所以适配器模式的适配器类最好采用私有继承的方式，以起到限定接口功能范围的作用。除此之外，在具体使用适配器模式的时候，还要尽量避免过多的嵌套适配，也就是不要不断地在适配器上增加适配器，我的建议是不要超过 3 次适配，超过了就要考虑是否需要重新设计接口功能。

原型模式可以说是创建型模式中灵活性最高的模式，不过在带来灵活性的同时，也带来了更大的风险，这对我们的设计与实现间接提出了更高的要求。你会发现，使用原型模式时可能需要我们对 IO 流、内存和 JVM 等一些底层的原理有更加深入的理解才行，虽然对象的拷贝看上去很容易，但是一旦使用不当，很容易就导致系统直接崩溃，这也是很多开发人员不愿意使用原型模式的原因之一。但是在很多类库和框架中，随处可见原型模式的身影，比如，JDK、Netty、Spring 等。

工厂方法模式的原理和使用都很简单，并且还可以很方便地通过子类进行定制，因此，在软件开发的早期，开发人员会很容易选择和使用工厂方法模式。另外，随着时间的推移，还可以将工厂方法模式演变为使用抽象工厂模式，进而极大地提升了程序的可扩展性。不过在我看来，如果对象的属性数量并不多，并且创建过程也不复杂的话，那么用不着使用工厂方法模式来创建对象，毕竟工厂方法模式强调使用继承来实现对象的创建，会引入继承相关的副作用。这里尤其要注意的是，工厂方法模式和抽象工厂模式虽然都用于创建对象，但是两者的侧重点是完全不同的。

在我看来，抽象工厂模式的使用和创建都很简单，不过这并不是应用这个模式的重点，重点其实在于能否明白抽象工厂模式的本质，也就是如何寻找到正确的抽象。只有找到了正确的抽象产品，才能发挥抽象工厂模式的作用，这样即便你的具体工厂全部是硬编码或烂代码，也依然不会掩盖优秀设计的光辉。换句话说，如果没有找到正确的抽象产品，那么你不应该急着去使用抽象工厂模式。如果只是想要封装对象创建过程，那么使用工厂方法模式完全可以满足要求的。

你会发现，在现实中，我们经常会遇见很多使用建造者模式的软件，比如，Maven、Ant 之类的自动化构建系统，再比如，Jenkins 等持续集成系统，它们实际上都是使用了建造者模式的具体例子。建造者模式的主要优点在于客户端不必知道对象内部组成的细节，将创建与使用进行了很好的解耦，使得我们可以使用相同的创建过程创建不同的对象，因此符合“开闭原则”，能够极大地提升代码的复用性。同时，因为每一个对象属性的创建步骤都被独立出来，所以还可以更加精细地控制对象的创建过程。不过，缺点也同样突出。

在我看来，学习设计模式时，除了要理解设计模式的原理之外，更重要的是要能获得启发——如何才能为真实的开发过程带来最大的实际价值（解决多少实际问题）。设计模式的底层逻辑就是：找到变化，封装变化。学习任何设计模式时，你都应该牢牢抓住这个本质核心，同时也要不断复习简单的学习框架，因为这在后面更多的模式学习中会起到关键的作用。除此之外，今天我们还主要介绍了单例模式，从定义到具体案例代码的分析，讲解了单例模式的适用场景以及使用后的收获和损失。

在 API 设计中，很多人会经常犯一个错误，那就是：想方设法地创建自己的 error code，用以表达自己对不同错误的个性化理解。但实际上，在 API 设计中，这是一种错误应用惯例原则的实践。在前面《14 | 惯例原则：如何提升编程中的沟通效率？》一文中，我们知道自定义惯例的风险就在于各自理解可能有偏差，进而导致业务更大的混乱。

关注点分离原则本质上就是要将复杂问题拆分为小问题，通过解决小问题来解决大问题。在架构设计视角下的关注点分离，能够帮助我们从具体的代码细节中抽离出来，关注上层组件之间的关系，从全局策略出发去优化整体。在编码实现视角下的关注点分离，能够帮助我们回到细节中，找出修改代码影响的边界范围，更好地做到局部的优化。关于如何使用关注点分离，只需要记住两个要点。第一个要点是在架构上做到策略和机制分离，换句话说，就是标准化，比如，HTTP 协议、Spring 框架等。重点关注的是整体系统的清晰与稳定。

惯例原则的初衷是提供隐形的公共知识，来减少开发人员重复决策的次数。惯例原则的优势在于能够帮助我们降低编程时的学习成本，不过它也有一些劣势，比如，可能导致设计的灵活性不足，乱用自定义惯例导致不同人按照各自的理解使用而引发问题，将参考的默认规则变成强制的主要规则，等等。惯例原则是程序员之间的共同行话，只要你用了一个惯例，那么对方便知道其中的意思。虽然惯例原则很简单，但是在日常开发中却应用很广泛。你在使用时应该注意：隐形的公共知识和大家的理解是不是一致的？

到此，今天的内容就讲完了。下面我们一起来总结和回顾一下这一讲你需要掌握的重点内容。1. 依赖反转原则（DIP）DIP 是一种设计理念，是为了帮助我们解耦复杂的程序。换句话说，DIP 是一种简单但功能强大的设计思想，我们可以使用它来实现结构良好、高度分离和可重用的软件组件。DIP 给我们带来一个重要启示：不管是程序设计还是工作生活，如果依赖和控制的东西过多了，就要学会制定标准，倒置依赖，反转控制，释放自身资源，专注于更重要的事。要让高层组件拥有定义抽象的权力，而不是把这个权力下放到低层组件。

SOLID 原则是面向对象编程中非常重要的指导原则，相信你在学习了上面的内容后，对于每个原则应该已经有一个大致的了解了。不过，你会发现，当你使用 SOLID 越多，代码的可重用性变得越来越高的同时，代码逻辑却也相应地变得越复杂。之所以会变得复杂，是因为 SOLID 原则太过于重视分离与灵活替换，这就意味着我们可能需要创建很多单一的类和方法，再通过接口把它们连接起来，这样反而容易让模块和模块之间的调用关系变得更错综复杂，增加了整体的复杂性。这显然违背了 KISS 原则。所以，

学习职责分离最重要的是要理解是什么原因引起了代码变化。搞清楚变化的原因，比一拿着需求就开始编码更为重要。在编码过程中，我们很多人总以为按照功能需求分配好了职责，代码就能按照职责运行了，但实际上可能一开始连职责都分配错了。比如，我现在对一些维护项目做 Code Review 时，还会偶尔遇见超大的类和方法，其中 90% 的维护人员给的理由都是不想到处跳转寻找代码，只修改一个文件更方便维护。但修改一个文件不代表不影响其他文件，因为变化的原因没有被真正找出来，这样错误的认知到后期常常都是要付出惨痛代价的。

表达原则的核心思想在于：通过代码清晰地表达我们的真实意图。虽然软件开发过程中会有诸多文档，比如，架构设计文档、流程文档、PRD 文档等，但这些文档并不足以帮助我们正确理解代码是如何运行和组织的，很多时候我们只能通过阅读代码来掌握软件的真实运行情况。我们之所以应该把提高代码可读性作为第一要务，就是因为读代码的次数远比写代码的次数多，包括你正在写的代码也是如此。今天我们学习了三种主要的改进办法：一是表层的改进，从命名、表达式、变量和注释入手去提升代码可读性；

迪米特法则（Law of Demeter，简称 LoD）一个类只应该与它直接相关的类通信；每一个类应该知道自己需要的最少知识。换句话说，在面向对象编程中，它要求任何一个对象（O）的方法（m），只应该调用以下对象：对象（O）自身；通过方法（m）的参数传入的对象；在方法（m）内创建的对象；组成对象（O）的对象；在方法（m）的范围内，可让对象（O）访问的全局变量。前面03讲我们讲过的分层架构，其实就可以被认为是迪米特法则在架构设计上的一种具体体现。

在软件开发中，简单性始终是一个最终的结果，然而为了达到这个结果，过程可能会非常复杂。我们看看各种操作系统、大型网站的简单性，背后其实是无数工程师辛勤地解决庞大的复杂性后才铸就的。如果我们只盯着简单，那么很快就会掉入我们自以为是的“简单思维”陷阱之中。KISS 原则的含义虽然很简单，但它其实只给了我们一个想要达成的目标，并没有给我们对应的方法。这也是简单原则让人非常迷惑的地方。把一件事情搞复杂往往很简单，但要想把一件复杂的事变简单，就是一件复杂的事。也就是说，

应用 DRY 原则最重要的是要搞清楚代码重复是不是就一定不好，而不能以是否违反了 DRY 原则为判断的依据。因为一旦以是否违反原则为标准，就会掉进上面所说的思维陷阱中。宁可重复，也不要错误的抽象。不要为了抽象而创建抽象。很多时候，我们容易将 DRY 原则理解为编程时不应该有重复代码，但其实这不是它的真实意图。在我看来，DRY 原则需要放到具体的上下文环境中去使用。比如，在技术选型时，可以用它来帮助我们看透组件复用的本质，还可以在功能实现时，用来减少各种新奇想法的冲突，而不是仅仅纠结于代码是否重复。

这里我先分享一个我的故事。刚学会编程时，我以为：高效编程 = 高效写代码。于是开启了疯狂写代码模式，在不停地编码与调试中，度过了一年又一年，并以此沾沾自喜。但这样坚持了很多年后，却慢慢发现自己的编程效率不仅没有提高，反而越来越慢。这时我意识到，整体编程效率之所以无法提升，是因为我一直都只是关注写代码的效率。这便带来三个问题：只关心代码是否正常运行，而对最终是否满足用户需求不在意；容易陷入代码细节而忽略整体，比如，系统设计、项目进度、与他人协作等；

编程语言是一种标准化的通信方式，用来向计算机发出指令。编程语言是对编程范式的一种工具技术上的支撑，一种语言可以适用多种编程范式。编程范式是一种根据功能对编程语言进行分类的方式，但它并不针对某种编程语言。所以，我们常说的面向对象编程其实是一种编程范式。面向对象编程有三大优势：模块化、对象结构和组合/聚合思想。你会发现，它们的核心理念都是在提升代码的可扩展性、可重用性和可维护性。

在了解软件工程之前，我们得先搞清楚什么是软件开发。软件开发，在狭义上的定义是指软件编程，也就是我们常说的编写和维护代码的过程。但其实，从广义上来讲，软件开发是指根据用户要求构建出软件系统或者系统中软件部分的一个产品的开发过程。换句话说，软件开发是一系列最终构建出软件产品的活动。现在，我们常用“软件开发过程”这个词来表述。软件开发过程 = 定义与分析 + 设计 + 实现 + 测试 + 交付 + 维护。不管是小到一个程序的某个模块的开发，还是大到行业级的软件项目，只要是软件开发，都离不开这个本质过程。

软件分层架构是通过层来隔离不同的关注点（变化相似的地方），以此来解决不同需求变化的问题，使得这种变化可以被控制在一个层里。对于功能性需求，将复杂问题分解为多个容易解决的子层问题；对于非功能性需求，可以提升代码可扩展性。总结来说，代码分层架构是一种软件架构设计方法。从软件的功能性需求角度看，分层是为了把较大的复杂问题拆分为多个较小的问题，在分散问题风险的同时，让问题更容易被解决，也就是我们常说的解耦。从架构（非功能性需求）角度看，分层能提升代码可扩展性，帮助开发人员在相似的变化中修改代码。其实，

Unix 设计哲学强调构建简单、清晰、模块化可扩展和数据驱动的代码。只有这样，代码才可以由其创建者以外的开发人员轻松维护和重新利用。Unix 早期创新性地提出了要进行模块化设计的思想改变，这个看似简单的改变，其实经过好长时间的演化后才成为今天的通用准则。所以，我们现在会理所应当地认为写代码就应该模块化、尽量可重用。但其实在软件开发的早期，那时的程序员并不这么认为，模块化在当时也并不很受欢迎，因为那时的计算机硬件很昂贵，在一个系统里集成更多的模块才是最佳选择。