前面通过实例解说了一个一环扣一环的面向对象的开发流程:用例模型 -> 领域模型 -> 设计模型(类模型 + 动态模型),解答了面向对象怎样做的问题。接下来我们就要讲“怎样做好面向对象设计”的技巧了
===================================================================
【内聚】
參考*的解释,内聚的含义例如以下:
cohesion refers to the degree to which the elements of a module belong together. (http://en.wikipedia.org/wiki/Cohesion_(computer_science)) |
翻译一下即:内聚指一个模块内部元素彼此结合的紧密程度。
看起来非常好理解,但深入思考一下,事实上没有那么简单。
首先:“模块”怎样理解?
你一定会说,“模块”当然就是我们所说的系统里的“XX模块”了,比如一个ERP系统的“权限”模块,一个电子商务的“支付”模块,一个论坛站点的“用户管理”模块。。。。。。等等
你说的没错,但在面向对象领域,谈到“内聚”的时候,模块的概念远远不止我们通常所理解的“系统内的某个模块”这个范围,而是可大可小,大到一个子系统,小到一个函数,你都能够理解为内聚里所说的“模块”。
所以,你能够用“内聚”来推断一个函数设计是否合理,一个类设计是否合理,一个接口设计是否合理,一个包设计是否合理,一个模块/子系统设计是否合理。
其次:“元素”到底是什么?
有了前面对“模块”的深入研究后,元素的含义就比較easy明白了(不同语言稍有不同)。
函数:函数的元素就是“代码”
类/接口:类的元素是“函数、属性”
包:包的元素是“类、接口、全局数据”等
模块:模块的元素是“包、命名空间”等
再次:“结合”是什么?
英文的原文是“belong”,有“属于”的意思,翻译成中文“结合”,更加贴近中文的理解。但“结合”本身这个词easy引起误解。绝大部分人看到“结合”这个单词,想到的肯定是“你中有我、我中有你”这种含义,甚至可能会联想到“美女和帅哥”的结合,抑或“青蛙王子和公主”的结合这种情况。
这种理解本身也并没有错,但比較狭隘。
我们以类的设计为例:假如一个类里面的函数都是仅仅依赖本类其他函数(当然不能循环调用啦),那内聚性肯定是最好的,由于“结合”得非常紧密。
但假设这个类的函数并不依赖本类的函数呢?我们就一定能说这个类的内聚性不好么?
事实上也不尽然,最常见的就是CRUD操作类,这几个函数相互之间没有不论什么结合关系(某些设计可能会先查询再改动,但这种设计不是事务安全的),但事实上这几个函数的内聚性非常高。
所以,关于内聚的结合概念,我觉得不是非常恰当的描写叙述。那么,就到底什么才是真正的“内聚”呢?
答案就藏在显而易见的地方,翻开你的词典,细致看看cohesion的含义,你会看到另外一个解释:凝聚力!
“凝聚力”就是“内聚”的核心思想,抛开面向对象不谈,我们日常工作中差点儿随处可见“凝聚力”:
你可能会说,你的团队非常有凝聚力。。。。。。
领导可能会说:我们要增强团队的凝聚力。。。。。。
成功学大师会说:凝聚力是一个团队成功的基石。。。。。。。
面向对象领域的“凝聚力”,和团队的“凝聚力”是一样的概念。
l 推断团队凝聚力时,我们关注团队成员是否都专注于团队的目标;推断面向对象模块的凝聚力时,我们相同关注元素是否专注于模块的目标,即:模块本身的职责!
l 推断团队凝聚力时,我们还会关注团队成员之间是否互相吸引和帮助;推断面向对象模块凝聚力时,我们相同关注元素间的结合关系;
尽管推断内聚性的时候我们会考虑元素的结合情况,但事实上是否专注模块的职责,才是内聚性的充要条件。
当模块的元素所有都专注于模块的职责的时候,即使元素间的结合不是非常紧密,也是符合内聚性的要求的,这也是CRUD设计符合内聚性的原因。
所以,推断一个模块(函数、类、包、子系统)“内聚性”的高低,最重要的是关注模块的元素是否都忠于模块的职责,简单来说就是“不要挂羊头卖狗肉”。
【耦合】
參考*,耦合的定义例如以下:
coupling or dependency is the degree to which each program module relies on each one of the other modules (http://en.wikipedia.org/wiki/Coupling_(computer_science)) |
简单翻译一下:耦合(或者称依赖)是程序模块相互之间的依赖程度。
从定义来看,耦合和内聚是相反的:内聚关注模块内部的元素结合程度,耦合关注模块之间的依赖程度。
理解耦合的关键有两点:什么是模块,什么是依赖。
什么是模块?
模块和内聚里面提到的模块一样,耦合中的模块事实上也是可大可小。常见的模块有:函数、类、包、子模块、子系统等
什么是依赖?
依赖这个词非常好理解,通俗的讲就是某个模块用到了另外一个模块的一些元素。
比如:A类使用了B类作为參数,A类的函数中使用了B类来完毕某些功能。。。。。。等等
================================================
转载请注明出处:http://blog.csdn.net/yunhua_lee/article/details/24481189
================================================