前面通过实例解说了一个一环扣一环的面向对象的开发流程：用例模型 -> 领域模型 -> 设计模型（类模型 + 动态模型），解答了面向对象怎样做的问题。接下来我们就要讲“怎样做好面向对象设计”的技巧了
===================================================================
【内聚】
參考维基百科的解释，内聚的含义例如以下：
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
================================================