代码耦合(转载)

作者:杨博链接:https://www.zhihu.com/question/21386172/answer/54476702来源:知乎著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。以前,我写代码时,我考虑模块(本文中的模块就是指单个源文件)的单向依赖关系,考虑接口的正交性和紧凑性。我觉得我在做低耦合的好设计。 然而,我发现其他程序员写的代码依赖关系混乱,接口臃肿,但他们仍然觉得自己写的代码耦合很低,设计很好。我这才发现,我理解的耦合和他们理解的不一样。他们理解的低耦合就是把代码提出来,让代码不要“乱”。然而,对于什么是“耦合”、什么是“乱”,他们并不知道有什么客观标准可以度量。 所以,现在我相信“耦合”是个有歧义的坏词,“低耦合”是个程序员经常误用的理论。我建议,设计架构、考察模块之间关系时,不要用“耦合”、“乱”这些无法度量的词语,而应该改用以下三个可以度量的指标:依赖、正交性、紧凑性。 依赖和耦合的最大区别在于,当我们说“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的咨询师邮件列表中就有人分享一些工具,用上述标准自动检查代码质量。那么将来你和别的程序员约架,你要喷对方代码写得烂,你就有了依据,因为你可以直接用工具给代码打分。 另外,将来如果有同事或者网友在讨论编程时,用了“耦合”、“解耦”、“乱”之类的混乱术语,你可以把这篇文章发给他看,然后鄙视他。