谈谈依赖和解耦

大型项目总避免不了各种模块间相互依赖，如果模块之间耦合严重，随着功能的增加，项目到后期会越来越难以维护。今天我们一起来思考下，大家常说的代码解耦到底要怎么做？

依赖是怎么产生的

既然要研究怎么让模块解耦，那当然要从根源来分析：依赖它到底从何而来？

依赖其实是在我们想把代码写好的那一刻开始产生的。为什么这么说呢？因为大多数代码都是可以通过像流水线一样写下来，最终变成一个几千行的函数、几万行的单个文件。这个时候甚至没有拆分成模块，也就更谈不上所谓依赖和解耦了。

忽然有一天，我们发现这种堆屎山的日子实在过的没有意思，开始研究怎么将一座大屎山拆成几个小屎山，然后再一点点清理干净。依赖的产生，就在我们一拆多的这个过程伴随出现的。

接口管理

当我们开始进行代码优化的时候，最先想到的就是将某些通用的功能抽象成单独的模块，通过提供接口这样的方式来给到需要的地方使用。

为了避免过度设计，我们会基于现有和可预见的需要进行设计。但日常的开发中，不可预见的问题定位和调整却占了大部分的时间。

例如，在做 To B 项目的时候，我们设计了一套完整的 API 给到对方，开始的时候大家都会按照这套接口来配合开发，其乐融融。突然有一天，老板拉了一个大客户，说这个客户的用户量会很大，必须要好好配合。老板一走，大客户马上化身甲方爸爸，说他们的接口已经写好了，友商都是按照他们的格式接入，都上线了。

遇到这种情况，通常我们会新增一个适配层，专门用于我们的服务和甲方爸爸之间的适配。

说了那么多，依赖在哪里呢？

依赖其实在接口设计完成的时候就出来了，虽然这是我们自己设计的接口，但它依赖于上游按照约定来调用。而上游有调整的时候，我们是需要跟随者适配或者调整的。

或者举个小一点的例子，我们在项目中使用了一个较出名的开源库。某一天该开源库升级版本了，新的版本不兼容旧的版本，同时声明旧的版本不会再继续维护了。这意味着如果我们不升级版本的话，后续旧的版本出现了 bug，我们只能自己啃源码来修复了。

这是来自于“甲方按照约定接口来调用服务”、“乙方按照约定接口来提供服务”的依赖。

状态管理

由接口管理产生的依赖通常来自外部，而应用内部也会有依赖的产生，常见的包括状态管理和事件管理。我们先来看看状态管理。

一个应用程序能按照预期正常运行，必然无法避免一些状态的管理。最简单的，生命周期就是一种状态。程序是否已经启动、功能是否正常运行、输入输出是否有变化，这些都会影响到程序的运行状态。

由于程序会有状态变化，因此我们的功能实现必然依赖程序的状态。例如，只有用户登录了才能进行更多的操作、订单产生了才可以进行撤销、界面渲染完成了用户才可以点击，等等。

从代码可读性和可维护性角度来看，面向对象编程近些年来还是稍胜于函数式编程，面向对象的设计本身就是状态设计的过程，而某个对象的运行结果，也会依赖于该对象的状态。

这是来自于对某个程序“按照预期运行”进行合理设计而产生的依赖。

功能管理

当我们根据功能将代码拆分成一个个模块之后，功能模块的管理也同样会产生一些依赖。

管理系统中最常见的就是面板的管理，对于每个面板来说，它应该只关心自身的状态。产品设计会要求我们在打开某个新的面板的时候，关闭其他面板；或是在点击面板以外的地方，关闭当前面板。这会涉及到面板与面板以外界面的通信，一般来说我们可以使用事件的方式来管理。每个面板在创建的时候，都需要监听外界的一个点击事件，并判断点击区域落在面板外面的时候，触发关闭。

某一天，产品提了个需求，所有的这些面板关闭的时候都要有一个动画效果，至于这个关闭动画的持续时间，要根据点击位置与面板的距离来计算。我们需要在点击事件触发的时候，把点击的位置告诉监听对象。

于是，我们全局搜了所有该类型事件的触发节点和监听节点，一一进行调整。

这是来自于对某个功能“不会发生变更”而产生的依赖。

依赖来自于约束

为了方便管理，我们设计了一些约定，并基于“大家都会遵守约定”的前提来提供更好、更便捷的服务。

举个例子，前端框架中为了更清晰地管理渲染层、数据层和逻辑处理，常用的设计包括 MVC、MVVM 等。而要使这样的架构设计发挥出效果，我们需要遵守其中的使用规范，不可以在数据层里直接修改界面等。

可以看到，依赖来自于对代码的设计。

依赖可以解耦吗

既然依赖来自于设计，为什么我们又常常说要进行模块间的解耦，降低模块间的依赖呢？

依赖的划分

我们先来看看一个问题，所有的依赖都需要解耦吗？

其实我们能看到，不合理的设计会导致代码间相互依赖，耦合严重。这种情况下，我们可以理解为产生了不合适的依赖。

而通常我们所说的设计解耦，则是通过合理的设计，恰到好处的职责和边界划分。此时，同样会产生一些约定，但这样的约定可以更好地管理我们的代码，此时可以理解为产生了合理的依赖。

因此，回到前面的疑问：既然依赖来自于设计，为什么我们要通过设计来降低依赖呢？显然，我们想要减少的，是不合理的依赖。而通过合理的设计，可以进行恰当的解耦。

无状态的函数式编程？

每个程序员对函数式编程都曾抱有过幻想，写多了面向对象编程的代码，对一些状态的管理和维护感到心烦。而无状态的函数式仿佛是白月光，可远观不可亵玩。

但即使是基于函数式编程设计的语言，写出来的功能也无法逃脱状态管理的命运。像 Clojure 编写的 Storm，也需要进行消息队列的管理、重启后服务的恢复等一系列状态管理。

在前端领域，React 同样基于函数式编程，但框架同样带有生命周期这样的状态。用 React 来实现的应用也依赖状态，因此同样产生了 Redux/Mobx 这样的工具来进行数据状态的管理工具。

应用程序无法离开状态的管理，是否意味着我们不需要函数式编程呢？并不是这样的。相反，我们需要对功能模块进行划分，划分出有状态和无状态的功能，来将状态管理放置到更小的范围，避免“牵一发而动全身”。

在这里，我们进行了状态有无的划分。

单向流的数据管理？

代码解耦的方式，其中也包括了使用单向数据流这种方式。

不管是 React 还是 Vue，都提供了单向数据流的管理工具。由于一个应用中，各个功能间都会有一些相互间的数据依赖，为了避免模块间的直接依赖，使用单向流的方式，可以将一些非模块内闭环的数据通过有序、单向的方式进行捆绑。通过这样的方式，模块之间的依赖解除了，调整为模块与数据流模块之间的依赖，代码的耦合程度得到缓解。

在这里，我们进行了模块内外数据的划分。