起因：模块独立性指每个模块只完成系统要求的独立子功能，并且与其他模块的联系最少且接口简单，
两个定性的度量标准――耦合性和内聚性。
耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越
紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方
式及传递的信息。
耦合性分类(低――高): 无直接耦合;数据耦合;标记耦合;控制耦合;公共耦合;内容耦合;
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，如何执行的操作，与我无关。