设计模式是开发同学经常聊到的话题，也经常被用到实际的开发项目中，熟练的人可以做到信手拈来，不熟悉的人陷入苦思冥想中。笔者认为，不仅仅要掌握设计模式的用法，更要洞察设计模式的底层逻辑，只有那样，才能做到遇到实际的问题可以使用合适的设计模式去解决。

一 你应该关注底层逻辑

1 设计模式的段子

段子一：你让他给你讲设计模式，他给你讲故事，听完后，又蹦又跳，乐坏了；看原著设计模式和实际写代码时，又是又蹦又跳，那是疯了。 段子二：你让他给你讲设计模式，他给你讲架构；你和他讲架构，他和你讲建筑学；你和他讲建筑学，他和你讲哲学…… 上面两个典型的段子，可以看到大家平时学习设计模式的无奈，故事听懂了，但依然没有掌握设计模式，甚至设计模式的类图大家也画得出，却还是不能灵活掌握设计模式。究其根本的原因是没有掌握设计模式的内核思想，只是知道设计模式的外在形式，相当于只学到了“招式”，没有学到“内功”。

2 底层逻辑的本质

很多事物都有底层逻辑，当掌握了事物的底层逻辑之后，很多事就好办了，如果你已经洞察到了最核心的规律，在实际工作中就只需要按照规律去执行就可以。例如，我们看到很多营销文案让人眼前一亮、叹为观止，如果要让我们去写这些营销文案，一开始还找不到门道，写出来的标题平平淡淡，不够吸引人。那营销文案背后的底层逻辑是什么呢？我们看到很多文案如“激发学习潜能的四大策略”、“如何在10天内记忆5000+单词”、“一文提示为什么你比别人差”……这些文案有的使用陈述手法，有的使用疑问手法，有的使用对比手法，有的使用感叹手法……再往下挖掘，不管使用哪种手法，本质来讲是命中了人的爽点或痛点，再用这个底层逻辑去看各种文案，有的命中你的痛点，比如你想记忆更多的单词，现实记不住单词；比如你想成功，但努力了很久还没有效果……有的命中你的爽点：你花更少的钱就能获得更好的服务；你不用出门就能赚到钱……当你洞察到了营销文案背后的底层逻辑，你现在也可以写出吸引眼球的文案，这就是底层逻辑的力量！ 我们学习23种设计模式，它们被划分成创建型设计模式、结构型设计模式、行为型设计模式，这就像营销文案的写作手法一样，那么设计模式的底层逻辑到底是什么呢？

二 设计模式的底层逻辑

1 设计模式的基石

平时我们在写代码的时候，经常见到如下三种类型的代码：面条型的代码、过程式的代码和面向对象的代码，这里以一个例子来说明这三种类型的编码特点。

• 面条型代码就是所有逻辑堆砌在一起，就像写一篇文章，不怎么分段落。比如古代雕刻文字，在一块木板上雕刻一首诗，如果诗人要把其中的一个修改下，那得重新雕刻这首诗。非常容易发现这种模式的缺点：耦合太严重，牵一发而动全身。

• 过程式代码在面条型代码基础上有了很大的进步，它遵循“自顶向下，逐步求精”的思想，把一个大问题划分成若干个小问题，分而治之。对应上面雕刻诗的例子，诗是由若干个行组成的，如果每块木板上只雕刻一行诗，万一要改某个字，只用重新雕刻那一行就行，不用重新雕刻整首诗。但如果要修改多个字，而且在不同的行时，这种极端情况下整个首诗又得重新雕刻了。

• 面向对象代码换了一种思考方式，诗是由行组成的，行又是由一个个字组成的，这也即是活字印刷的思想，这些字还可以复用于其它不同的诗，复用性非常强。

从上面的例子可以看到，核心还是洞察到事物的结构和关系，首先回答的是what，而不是how。过程式就是过分强调了how，一开始就思考怎么去做，过程式思维是以自己为中心，导演了整个功能流程，自己承担了太多自己不应该承担的职责，整个设计就显得不灵活。面向对象是从对象的角度去看问题，解决问题是由各个对象协作完成，设计模式的基石就是面向对象，脱离了面向对象去谈设计模式那是耍流氓。

2 设计模式的鼻祖

设计模式有一本经典的书籍：《设计模式：可复用面向对象软件的基础》，在书中作者提到了一句话：“找到变化，封装变化”，这才是设计模式的底层逻辑。很多人忽视了这句话，反而去追寻各种模式的招式，遇到实际的问题又找不到合适的设计模式去解决了。“找到变化，封装变化”非常精练地提示了设计模式的本质，细细品味这句话，再去看23种设计模式，每种设计模式都在应对变化的事，比如策略模式，具体的策略在变化；工厂模式，创建的对象在变化；模板模式，具体模板算法实现在变化……这就好比营销文案的底层逻辑：命中了你的痛点或爽点，具体痛点和爽点是什么需要去寻找。在实际问题中，需要我们去看什么在变化，选择哪种设计模式比较合适。

3 再谈底层逻辑

再回过头看底层逻辑，平时我们看到的现象只是现象层，核心是要洞察到事物的底层逻辑，只有那样才能真正理解现象、运用规律，如果你不懂营销文案背后的底层逻辑，你所有的勤奋都是低水平的重复，很难写出高质量的营销文案，偶尔一两次起得了良好的效果你也不知道为什么能吸引人。设计模式也是一样，你能熟悉地画出各种模式的UML图，可你依然还是用不好设计模式，本质还是没有掌握设计模式的底层逻辑，只看到了设计模式的现象层的招式。设计模式的底层逻辑是“找到变化，封装变化”，这里就有两个问题：什么在变化，如何封装变化，大师以为我们都知道，所以并没有讲具体怎么去寻找变化，怎么去封装变化。接下来具体谈谈怎么去运用设计模式的底层逻辑。

三 设计模式要回答的两个问题

1 什么在变化

“找到变化，封装变化”这句话，首先要回答的是什么在变化，如果变化没有找到，就不可能封装变化。笔者这里以对象生命周期的视角去看待对象的变化，对象是由创建而产生，然后被使用，最后是消亡。对象有三个不同维度的变化：对象结构的变化、对象规格的变化、对象行为的变化。以对象结构变化为例，对象的关系划分成两类：线性关系和非线性关系（树和图），在线性关系中，如何解决一个对象的变化不会影响到关联的对象？在树型结构中，如何解决不断新增加对象的问题？在图型结构中，如何解决用户方便使用复杂系统的问题？ 找到变化是最为关键，不同的业务问题，遇到的变化问题也是不一样的，核心是要找到这些变化。比如对象规格的变化，有数量的变化、类型的变化、外观的变化，在实际编码的过程中就要有这种思考，比如创建一个对象，再深入思想下，有没有其它类型的对象？数量有没有变化？……只有找到了这些变化，具体怎么去封装变化就是技术的问题，接下来讨论如何封装变化。

2 如何封装变化

从封装的类型上看，有数据的封装、方法的封装、类型的封装等。就具体的封装方法而言，常见的有配置项、接口、抽象方法、类、注解、插件等具体的手段，再往上看主要使用了继承、组合的方法，再往上看封装的原则，常见的原则有单一职责、开闭原则、依赖倒置、隔离原则……大部分人平时更多地关注如何封装变化，并没有深入去思考什么在变化。

四 用底层逻辑推导结构型设计模式

1 寻找对象结构的变化

从UML看，对象之间的关系有依赖、泛化、组合、聚合，但就结构关系上看只有两种，线性关系和非线性关系。线性关系比较简单，就是一对一的关联关系，非线性关系分成两种：树型关系和图型关系。 关系结构有变化，意味着依赖发生了变化，比如线性关系中的变化，A依赖的B发生了变化，此时B变化了就会影响A，怎么做到B的变化不影响A就是要考虑的问题。

2 应对线性变化

如上面所讲，如果B发生了变化，由于A依赖B，则对象A也要改变化，如何减少对A的影响呢？这里有两种方法：一种是通过增加适配来解决，另一种是通过代理来解决。这两种方法的要点都是一个对象不与变化的对象直接关联，不管是适配还是代理，都是引入了第三方来与B关联，第三方负责与B进行交互，B对A是没有感知的。有的人马上发现了一个问题，这不是把问题转移到第三方上了吗？乍一看，还真是这么回事，如果我们再发散思考，如果除了A要与B关系，还有E、F……，如果B一改就关联的所有对象就要变化，这种代价就比较高，如果只与第三方关系，只用改一个地方，成本要少得多。

3 应对非线性变化

非线性关系比线性关系要复杂，常见也有两种方法：一种是通过注册机制，另一种通过抽象层屏蔽复杂性。当一个对象包含多个对象时，如果直接去管理，需要承担的职责太多，通过注册机制就比较好解决，增加一个对象，是通过注册机制主动告知对象。另外一种方法就是通过抽象层屏蔽复杂性，比如门面模式，在门面内把所有的复杂度都规避，对外提供简洁的接口。

五 业务变化之道

设计模式还是要应用到实际的业务中才能发挥它的价值， Alan Shalloway 提到一个观点：无法预测哪里有变化，但能知道哪里可能有变化。平时我们在做业务需求开发时，要有这种识别变化的意识，先不要陷入面向过程的思维中，不要一上来就考虑如何去实现，而是思考它是什么，会有哪些变化，比如对象的数量、对象的外观、对象的种类……当把这些思考清楚之后，才能设计得更合理。 比如笔者之前做清结算业务时，投资人理财到期后，会将本息金额的钱打给投资人，刚开始只有大华支付通道，这里就要想到一个问题，大华支付只是一种具体的实现方式，还会有没有其它的支付方式，如果有就要做抽象设计，设计一个通用的支付模板类，每接一种新的支付通道时，只用重写模板类中的几个方法即可，后续又接了民生银行支付、连连支付。

六 对象设计之道

有了前面所讲内容的铺垫，这里再深入总结下对象设计的一些思考。对象设计有三个问题：有哪些对象？对象之间的关系是怎样的？对象的职责有哪些？当把这三个问题梳理清楚了，对象设计也就容易得多，也是面向对象分析与设计的核心。正常来讲，我们知道结构决定功能，功能决定行为，这是非常符合人的逻辑认识，但要想了解清楚对象的结构又是非常难的，就像新冠病毒的分子结构也不是那么容易破解的，尤其是复杂业务，它所包含的业务对象并不那么容易弄清楚它的结构。 我们可以反过来思考，当有一种业务场景时，先思考它的职责是什么，再去思考应该由哪些业务对象去承担，这也是典型的归纳思维。比如在优惠券业务中，它的业务活动就三个：建券、发券、用券，也就是任何一个优惠券系统，它要提供这三个最为基础的能力，这三个能力又对应到两个业务对象：券批次和券实例，券批次相当于是券的模板，告知优惠券的预算有多少、券面额是多少、使用条件是什么……，具体发放到用户手上的才是券实例。 当有了业务对象之后，就要通过用例去思考对象模型的所包含的属性和方法有哪些，这个过程并不是一次就能完美完成的，而是通过多次打磨才行，这里面就要遵循一些原则，比如单一职责、开闭原则、依赖倒置的原则……，让整个模型的可扩展性更好。

七 一个案例

最后拿一个案例来讲，店铺类目是卖家为了方便买家有针对性地选购商品而对商品做出的归类，比如上新类目，把最近30天上架的商品归类在一起，方便买家查找。遇到的挑战就是怎么用一套业务模型去支持不同业务方高度定制化的需求，有的需求方要求有三级类目，有的业务方要求浮动的两级类目，同时圈品方式也不一样，有的业务方要求有自动圈选商品，圈选商品的条件还不一样，如按价格圈选、按商品上架时间圈选、按评价圈选…… 怎么去设计这套模型呢，还是从店铺类目的定义去看，店铺类目至少包含两个关键的要素：类目结构和类目圈品，因为归类产生了结构，商品产生了圈品，考虑到类目有不同的层级和圈品条件，所以第一版模型就很快设计出来了，从模型中可以看到能支撑业务的诉求，尤其是圈品条件中业务方可以自定义各种条件注册到平台上，看到这个设计，笔者内心还是欣慰的。 但在实现的过程中，发现了一些问题，如根类目和子类目，在业务模型中有这两个概念，在代码上也要有这两个概念，正是引入了这两个概念，代码写起来就比较麻烦，本身它们并没有什么区别，现在人为地把它们区分开来，很多逻辑都要写两遍。笔者又进模型进行了优化，变成了第二版模型，这个模型就更简单了。 这里想谈的两点是要保证模型的简洁性和降低技术复杂度，技术人喜欢钻研技术，喜欢把一些学到的技术应用到项目中，这实际上是一种技术偏见，以为这样才能体现出技术复杂度和技术能力。复杂并不见得有技术含量，就像设计模式的底层规律，作者并没有长篇大谈，而是只有8个字"找到变化，封装变化"，大道至简就是这个道理，我们学习设计模式，不要为了用设计模式而用，一定要思考为什么用，解决了什么问题，这样才有价值。