注册 登录  
 加关注

网易博客网站关停、迁移的公告:

将从2018年11月30日00:00起正式停止网易博客运营
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

为着理想勇敢前进

 
 
 

日志

 
 

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

2015-07-10 19:00:02|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

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

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

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

依赖和耦合的最大区别在于,当我们说“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个。

总之,单向依赖、正交性、紧凑性这三个指标都很务实,有客观方法可以度量。
我觉得也许可以代替“低耦合”这种“公说公有理婆说婆有理”的务虚理论。
比如前两天我们ThoughtWorks的咨询师邮件列表中就有人分享一些工具,用上述标准自动检查代码质量。
那么将来你和别的程序员约架,你要喷对方代码写得烂,你就有了依据,因为你可以直接用工具给代码打分。

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

  评论这张
 
阅读(1049)| 评论(1)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018