《追求优雅的代码之用设计模式让代码更优雅》

链接

大家晚上好，很高兴能够为大家带来这次分享，不好意思鸽了一下，业务太忙了。本次为大家分享的主题是追求优雅的代码之用设计模式让代码更优雅。

讲到设计模式，大家一定有使用过和了解过，关于什么是设计模式，我总结了一句话：场景下的“最佳”解决方案。这里的最佳我给他划了一个下划线是因为他是在某个场景某个情况（某个时空）下的最佳解决方案，并且这里的最佳也是相对的。

所以设计模式，他存在的目的也很简单。

为了复用代码、提升可维护性、提升性能等等…… 总之，就是让你的代码更优雅。

可以说是无处不在，处处都存在设计模式。那么我找了几个设计模式为切入点，为大家介绍使用设计模式如何让你的代码更优雅。

观察者模式，浏览器环境的事件监听就使用了这个模式，当然 DOM 事件触发后执行注册过的回调函数，并且实现一对多的通知功能，也体现出观察者模式的优势就是可以在任意代码位置进行订阅或解除订阅。

比如让我们来看到观察者模式，一般初学者容易忽略的使用技巧导致后期排查问题费了很多时间，其实凡是遇到观察者模式，就一定会有订阅和解除订阅，而初学者特别容易忘记的就是解除订阅而产生重复的通知，从而产生问题。

原型模式，相信大家都很熟悉，JavaScript 就是基于原型设计的语言。这个例子不是很恰当，也不是很直观，不过没关系，我就是想简单介绍一下这个模式。大家看一下即可，Zong 在实例化以后可以调用原型 Human 的方法。

再来说到一些原型链的问题，我找了一个比较常见的例子，就是 hasOwnProperty 这个方法，我们看到代码……

这里使用到的 Father 和 Child 命名空间并不恰当，不属于继承关系。

尝试看到这段代码……

Mixin 模式，我们来看到这段代码，代码中 Class 类沿用原型模式的例子，而 mixin 则是类似“人”的一些通用能力的复用，如 sayHi 和 sleep ，可以用在不同的“人”上。使用 Mixin 可以扩展功能，看到代码第 22 行。我们可以使实例化后的 zong1 获得 sayHi 的功能，当然问题也同样暴露出来了，那就是原有的 sleep 被 Mixin 中的 sleep 覆盖。他对原有的类造成了污染，所以使用 Mixin 模式的时候要格外小心，因为或许你一个人注意也无济于事，当项目经由多人协作时，不熟悉项目获不熟悉 Mixin 的开发者使用或不使用 Mixin 都会产生不小的影响。

那么如此容易出现问题的 Mixin 模式在目前也有不少的解决方案，如 Vue 采用 Composition API ，React 采用高阶组件（HOC）也就是高阶函数来解决问题，推荐大家在平时开发时采用此类设计模式解决问题。

水了一会时间，上面我挑选了几个设计模式和大家进行了简单的介绍，其他的设计模式有兴趣的同学可以通过网上查阅和学习，就简单说到这里了。那么接下来，分享一些我自己的经验之谈，当然因为时间紧迫加上平时没有将一些技巧及时总结下来，导致短时间内没回想起多少经验，比如设计模式带来的好处、如何组合设计模式提供特殊场景下的解决方案。

在日常的 B 端开发过程中，相信大家见的最多的就是 CRUD 基本操作了。也相信大家已经厌倦了 CV 的操作，并且这样做非常的不优雅，所以大家会想办法抽离并抽象这部分 CRUD 的代码，最早接触到的设计模式就是 Mixin 模式，在 React 或 Vue 中都有 Mixin 的使用方法，非常的方便。当然了，前面提到了 Mixin 的缺陷也是必然存在的，说起来也很不好意思，比如我刚入职那会在改公司项目的时候，就是因为不熟悉项目，所以没有充分很好的利用 Mixin ，而全部自己手写了一套 CRUD 代码，当我写完后我才发现居然可以直接使用 Mixin ，讲实话非常的难过。

当然了，这已经成为历史。现在我们可以拥抱高阶组件、Composition API 来真正的抽象所需要的代码，让我们写的代码变得优雅起来。

目前 Composition API 基本支持 Vue 2 和 Vue 3 ，建议大家可以尝试使用起来，嘿嘿，安利一波优雅的心态。

说了这么多，所以类似于高阶函数、组合式API他们只是简单的解决了 CV 问题吗？

高效开发
专注调试（当出现程序缺陷时，可以只在关键的代码位置进行调试，这时候就体现出单元测试的重要性了，所以必要的时候还是要写单元测试噢～）
高安全性（这一点是基于单元测试的，如果说你抽象出来的代码包含了较为完整的测试用例和较高的覆盖率的话，你所抽象的代码将会显得可靠。）
易用易维护（这一点与前面没有较大的关联，他体现在你抽离的代码自身是否应用了比较好的设计模式，比如使用插件模式设计功能等等……）
低代码基石（这一点是我认为在近段时间就可以落地的想法，当大家把业务中的逻辑，像是 CRUD 做到合理的抽象、安全性的保障，那么他就是低代码平台的基石，低代码平台或零代码平台就是依托于此，让非专业开发人员完成 CRUD 等业务逻辑的组合。）

那么这个场景下使用设计模式解决问题，可以带来这些好处。当然在其他场景下也同样的会有另外的好处。

总之，就和没有绝对的对错一样，没有绝对的优雅，所以坚持你的坚持，定会有所成果。

其实身边，还有很多可以提升代码优雅，让你的代码变得优雅的地方和机会，有兴趣的同学可以，如果愿意的话，我们可以在日常工作中多多讨论此类问题。