起因：模块独立性指每个模块只完成系统要求的独立子功能，并且与其他模块的联系最少且接口简单，

两个定性的度量标准――耦合性和内聚性。

    耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越

紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方

式及传递的信息。

    耦合性分类(低――高): 无直接耦合;数据耦合;标记耦合;控制耦合;公共耦合;内容耦合;

1 无直接耦合:

2 数据耦合: 指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言的值传递;

3 标记耦合: 指两个模块之间传递的是数据结构，如高级语言中的数组名、记录名、文件名等这些名字即标记，其实传递的是这个数据结构的地址;

4 控制耦合: 指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该控制变量的值有选择地执行块内某一功能;

5 公共耦合: 指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加。

6 内容耦合: 这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部。

    内聚性又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的

度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。

    内聚性匪类(低――高): 偶然内聚;逻辑内聚;时间内聚;通信内聚;顺序内聚;功能内聚;

1 偶然内聚: 指一个模块内的各处理元素之间没有任何联系。

2 逻辑内聚: 指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。

3 时间内聚: 把需要同时执行的动作组合在一起形成的模块为时间内聚模块。

4 通信内聚: 指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据。

5 顺序内聚: 指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一功能元素的输入。

6 功能内聚: 这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。与其他模块的耦合是最弱的。

    耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。

    有个例子很容易明白：一个程序有50个函数，这个程序执行得非常好；然而一旦你修改其中一个函

数，其他49个函数都需要做修改，这就是高耦合的后果。

一旦你理解了它，你编写概要设计的时候设计类或者模块自然会考虑到“高内聚，低耦合”。

耦合指的模块之间的关系，最弱的耦合设计是通过一个主控模块来协调n个模

块之间的运作。还是举一个我举过的例子：客户要求在界面上增加一个字段，

你的项目要修改几个地方呢？如果你只要修改项目文档，那么你的开发构架就

是最低强度的耦合，而这种设计 成熟的开发团队都已经做到了，他们使用开发

工具通过项目模型驱动数据库和各层次的代码，而不是直接修改那些代码；

内聚指的是模块内部的功能，最强的内聚就是功能单一到不能拆分，也就是原

子化，所以强内聚和弱耦合是相辅相成的，一个良好的设计是由若干个强内聚

模块以弱耦合的方式组装起来的

1. 低耦合（Low Coupling）

“低耦合”这个词相信大家已经耳熟能详，我们在看spring的书籍、MVC的数据、设计模式的书籍，无处不提到“低耦合、高内聚”，它已经成为软件设计质量的标准之一。那么什么是低耦合？

耦合就是对某元素与其它元素之间的连接、感知和依赖的量度。这里所说的元

素，即可以是功能、对象（类），也可以指系统、子系统、模块。假如一个元

素A去连接元素B，或者通过自己的方法可以感知B，或者当B不存在的时候就不

能正常工作，那么就说元素A与元素B耦合。耦合带来的问题是，当元素B发生变

更或不存在时，都将影响元素A的正常工作，影响系统的可维护性和易变更性。

同时元素A只能工作于元素B存在的环境中，这也降低了元素A的可复用性。正因

为耦合的种种弊端，我们在软件设计的时候努力追求“低耦合”。低耦合就是

要求在我们的软件系统中，某元素不要过度依赖于其它元素。请注意这里

的“过度”二字。系统中低耦合不能过度，比如说我们设计一个类可以不与JDK

耦合，这可能吗？除非你不是设计的Java程序。再比如我设计了一个类，它不

与我的系统中的任何类发生耦合。如果有这样一个类，那么它必然是低内聚

（关于内聚的问题我随后讨论）。耦合与内聚常常是一个矛盾的两个方面。最

佳的方案就是寻找一个合适的中间点。

目前已经有大量的框架帮助我们降低我们系统的耦合度。比如，使用struts我

们可以应用MVC模型，使页面展现与业务逻辑分离，做到了页面展现与业务逻辑

的低耦合。当我们的页面展现需要变更时，我们只需要修改我们的页面，而不

影响我们的业务逻辑；同样，我们的业务逻辑需要变更的时候，我们只需要修

改我们的java程序，与我们的页面无关。

使用spring我们运用IoC（反向控制），降低了业务逻辑中各个类的相互依赖。

假如类A因为需要功能F而调用类B，在通常的情况下类A需要引用类B，因而类A

就依赖于类B了，也就是说当类B不存在的时候类A就无法使用了。使用了IoC，

类A调用的仅仅是实现了功能F的接口的某个类，这个类可能是类B，也可能是另

一个类C，由spring的配置文件来决定。这样，类A就不再依赖于类B了，耦合度

降低，重用性提高了。

使用hibernate则是使我们的业务逻辑与数据持久化分

离，也就是与将数据存储到数据库的操作分离。我们在业务逻辑中只需要将数

据放到值对象中，然后交给hibernate，或者从hibernate那里得到值对象。至

于用Oracle、MySQL还是SQL Server，如何执行的操作，与我无关。

下载文档

本文出自 “我的JAVA世界” 博客，请务必保留此出处http://hanchaohan.blog.51cto.com/2996417/1438990