转自知乎
杨博
AI/前端库DeepLearning.scala/Binding.scala作者
314 人赞同了该回答
以前，我写代码时，我考虑模块（本文中的模块就是指单个源文件）的单向依赖关系，考虑接口的正交性和紧凑性。
我觉得我在做低耦合的好设计。
然而，我发现其他程序员写的代码依赖关系混乱，接口臃肿，但他们仍然觉得自己写的代码耦合很低，设计很好。
我这才发现，我理解的耦合和他们理解的不一样。
他们理解的低耦合就是把代码提出来，让代码不要“乱”。
然而，对于什么是“耦合”、什么是“乱”，他们并不知道有什么客观标准可以度量。
所以，现在我相信“耦合”是个有歧义的坏词，“低耦合”是个程序员经常误用的理论。
我建议，设计架构、考察模块之间关系时，不要用“耦合”、“乱”这些无法度量的词语，而应该改用以下三个可以度量的指标：依赖、正交性、紧凑性。
依赖和耦合的最大区别在于，当我们说“A和B耦合”时，在字面含义中，A和B二者平等。
然而，正确的模块关系根本不应该平等，而应该是单向依赖才对。
所以我们应该说“A依赖B”，这样含义要清楚得多。
A依赖B意味着，A模块可以调用B模块暴露的API，但B模块绝不允许调用A模块的API。
单向依赖是红线，好的设计一定不会违反这条红线。
注意：根据实质重于形式原则，本文中的“依赖”指人脑中的依赖而不是编译器的依赖。
只要程序员编写模块A时，需要知道模块B的存在，需要知道模块B提供哪些功能，A对B依赖就存在。
甚至就算通过所谓的依赖注入、命名查找之类的“解耦”手段，让模块A不需要import B或者include "B.h"，人脑中的依赖仍旧一点都没有变化。
唯一的作用是会骗过后文会提到的代码打分工具，让工具误以为两个模块间没有依赖。
所以
@翟志军
的例子中的解耦只是在自娱自乐兜圈子而已。
因为不管你用什么技术手段，Configuration的调用方程序员总是需要知道配置项的具体业务含义才能用啊。
很多程序员觉得“耦合”是坏事，爱写兜圈子的代码来消除所谓的“耦合”。
但是我们改用“依赖”术语后，我们就发现单向依赖不是坏事，根本不必费心消除，
因为，真正的重点是，依赖关系中，被依赖方暴露的接口能不能足够“正交”和“紧凑”。
正交性是指一个模块提供的API中，多个方法之间是否有重复的功能。
如果有重复功能，正交性就差。
通常，正交性高的模块更稳定，不会因为上层业务变化而被迫修改代码。
好的API内部的多个方法之间不应该有任何重复功能，只实现正交的机制。
如果感觉拆得太细使用不便，应该在底层API之外包装出一层Helper、Utility组成的胶水层。
胶水层调用底层原语API来实现常用模式供上层使用。
对于胶水层中的模块，对正交性的要求可以稍低一些。
注意上层代码既可以直接调用正交的底层API，又可以调用胶水层的常用模式。
紧凑性是指一个模块提供的API中，公有方法总数必须很少，每个方法的参数也必须很少。
《Unix编程艺术》上说一个模块不要超过7个方法，不然就很难理解。
但我实践中发现，我一般编写的模块，公有方法通常不超过3个。
总之，单向依赖、正交性、紧凑性这三个指标都很务实，有客观方法可以度量。
我觉得也许可以代替“低耦合”这种“公说公有理婆说婆有理”的务虚理论。
比如前两天我们ThoughtWorks的咨询师邮件列表中就有人分享一些工具，用上述标准自动检查代码质量。
那么将来你和别的程序员约架，你要喷对方代码写得烂，你就有了依据，因为你可以直接用工具给代码打分。
另外，将来如果有同事或者网友在讨论编程时，用了“耦合”、“解耦”、“乱”之类的混乱术语，你可以把这篇文章发给他看，然后鄙视他。