不要过分解耦了

最近一年半时间在高强度、集中性的做客户端所谓架构方面的工作。这些比代码更抽象的东西很少有人聊到，也很难搜索和交流，会陆陆续续写一些思考。

关于耦合

每一个程序员在接受中等甚至初级培训的时候都会被不停的灌输一个概念：耦合是坏的。但是，耦合的来源是什么？解耦的目标是什么？什么样的耦合是不好的？这些似乎没有人提过。

耦合的来源是什么

耦合通常来自两个方面：

• 代码写挫了。主要包括：
  • 耦合边界不合理，导致很多相互调用的逻辑
  • 不该复用的地方硬生生搞复用
  • 不合理使用继承等扩散内部细节的手段进行复用
  • 层级设计不合理
  • 等等
• 业务上天然存在的耦合，比如首页就是要打开详情页，二者是天然要耦合的。

解耦的目标是什么

解耦和客户端架构的目标是一致的，都是为了又快又好的进行业务开发。不好的耦合一方面会导致代码难以读懂（修改困难）、依赖非常复杂（打包慢）；另一方面会导致单点错误或者修改传递到不希望修改的部分（其实是复用的问题，导致隐藏 bug）。所以要把不好的耦合解掉。

什么样的耦合是不好的

当然是代码写挫了这种。

物理和逻辑耦合

• 物理耦合
  代码上的真实依赖。反映到文件上非常明确：代码调用、继承、持有都算是，这些耦合简单来说都可以靠自动化的静态分析搞定。
• 逻辑耦合
  A 依赖 B 的执行状态、修改的全局状态、逻辑上需要使用 B 都算是，通常是不太容易用静态分析搞定的。

所以我的态度来了 耦合是有物理耦合和逻辑耦合之分的，解耦的上限应该是逻辑耦合。如果只是将物理耦合解掉，逻辑耦合不动，那这个解耦一定是有害的！

想喷的现状

这个文章的来源是在面试过程中，甚至是大厂开源的框架里，嗅到了一股浓浓的没想好就瞎解依赖的味道。
看现在的几乎所有路由框架，都在做什么？用字符串 + 参数 map 的形式把跳转“解耦”掉，甚至有人把方法调用都做成了字符串 + 参数 map 的形式！硬生生把必须存在的（逻辑+物理）耦合用这种方式干掉了物理耦合。逻辑耦合仍然存在的情况下，这种解耦的效用是什么呢？
完全不可维护，以及繁重的线下沟通工作！
Java 可能少数几个优势就是强类型，这种解耦一下子就把强类型转成了弱类型。编译没毛病，一跑崩成狗。如果喜欢这种感觉请去写 groovy，请尽可能的使用环境变量，请尽量搞一万个全局 flag。所以，这种写法根本没法修改接口！接口的修改必须靠非代码的方式进行全局的传播，在一个超过50人的团队里，这个一定是会出 bug 的。而且接口的定义必须是用文档维护的（否则就得共享所有代码），这个额外成本根本是在浪费。
如果想解耦，请把逻辑耦合用合理的方式去掉；把去不掉的耦合用最明确、最代码的形式以物理耦合的方式暴露出来，用代码库做程序员沟通的手段，用编译尽早发现问题！