极简设计

为什么模块“耦合性”概念该要摒弃

以前写代码时,考虑模块(此处指单个源文件)的单向依赖关系、接口的正交性和紧凑性,我觉得我在做低耦合的好设计

然而发现其他程序员写的代码依赖关系混乱,接口臃肿,但他们仍然觉得自己写的代码耦合很低,设计很好 我这才发现,我理解的耦合和他们理解的不一样 他们理解的低耦合就是把代码提出来,让代码不要“乱” 然而,对于什么是“耦合”、什么是“乱”,他们并不知道有什么客观标准可以度量

所以,现在我相信“耦合”是个有歧义的坏词,“低耦合”是个程序员经常误用的理论 建议,设计架构、考察模块之间关系时,不要用“耦合”、“乱”这些无法度量的词语,而应该改用以下三个可以度量的指标:依赖、正交性、紧凑性

依赖和耦合的最大区别在于,当我们说“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”,人脑中的依赖仍旧一点都没有变化 唯一的作用是会骗过代码打分工具,让工具误以为两个模块间没有依赖

很多程序员觉得“耦合”是坏事,爱写兜圈子的代码来消除所谓的“耦合” 但是我们改用“依赖”术语后,我们就发现单向依赖不是坏事,根本不必费心消除, 因为,真正的重点是,依赖关系中,被依赖方暴露的接口能不能足够“正交”和“紧凑”

正交性是指一个模块提供的API中,多个方法之间是否有重复的功能 如果有重复功能,正交性就差 通常,正交性高的模块更稳定,不会因为上层业务变化而被迫修改代码 好的API内部的多个方法之间不应该有任何重复功能,只实现正交的机制

如果感觉拆得太细使用不便,应该在底层API之外包装出一层Helper、Utility组成的胶水层 胶水层调用底层原语API来实现常用模式供上层使用 对于胶水层中的模块,对正交性的要求可以稍低一些 注意上层代码既可以直接调用正交的底层API,又可以调用胶水层的常用模式

紧凑性是指一个模块提供的API中,公有方法总数必须很少,每个方法的参数也必须很少 《Unix编程艺术》上说一个模块不要超过7个方法,不然就很难理解 但我实践中发现,我一般编写的模块,公有方法通常不超过3个

总之,单向依赖、正交性、紧凑性这三个指标都很务实,有客观方法可以度量,也许可以代替“低耦合”这种“公说公有理婆说婆有理”的务虚理论 那么将别的程序员约架,要喷对方代码写得烂,就有了依据,因为可以直接用工具给代码打分

另外,将来如果有同事或者网友在讨论编程时,用了“耦合”、“解耦”、“乱”之类的混乱术语,可以把这篇文章发给他看,然后鄙视他

看问题不仅要定量的,有时也需要定性的 既要能从细节入手,也要能从高层次把控

另外,有些时候,耦合其实不是耦合,是聚合。高聚合是有益的 还有些时候,即使是真正的耦合,也可能是有益的,因为代码该怎么写不仅仅是要符合设计原理,更需要能有效的解决实际的问题

当然,探讨如何定量的分析耦合,是值得肯定的

in arch with : arch