高内聚低耦合1．什么是内聚？什么是耦合？内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。

它描述的是模块内的功能联系；耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。

耦合性也称块间联系。

指软件系统结构中各模块间相互联系紧密程度的一种度量。

模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。

模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。

2．内聚分为哪几类？耦合分为哪几类？内聚有如下的种类，它们之间的内聚度由弱到强排列如下：（1）偶然内聚。

模块中的代码无法定义其不同功能的调用。

但它使该模块能执行不同的功能，这种模块称为巧合强度模块。

（2）逻辑内聚。

这种模块把几种相关的功能组合在一起，每次被调用时，由传送给模块参数来确定该模块应完成哪一种功能（3）时间内聚：把需要同时执行的动作组合在一起形成的模块为时间内聚模块。

（4）过程内聚：构件或者操作的组合方式是，允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。

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

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

（7）功能内聚：这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。

耦合可以分为以下几种，它们之间的耦合度由高到低排列如下：（1）内容耦合：如果发生下列情形，两个模块之间就发生了内容耦合•一个模块直接访问另一个模块的内部数据•一个模块不通过正常入口转到另一模块内部；•两个模块有一部分程序代码重叠(只可能出现在汇编语言中)；•一个模块有多个入口。

（2）公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。

公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

（3）外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。

（4）控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合（5）标记耦合：一组模块通过参数表传递记录信息，就是标记耦合。

这个记录是某一数据结构的子结构，而不是简单变量。

其实传递的是这个数据结构的地址；也就是地址传递。

（6）数据耦合：指两个模块之间有调用关系,传递的是简单的数据值，一个模块访问另一个模块时，彼此之间是通过简单数据参数(不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的,相当于高级语言的值传递。

（7）非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。

耦合强度，依赖于以下几个因素：（1）一个模块对另一个模块的调用；（2）一个模块向另一个模块传递的数据量；（3）一个模块施加到另一个模块的控制的多少；（4）模块之间接口的复杂程度。

1、耦合、内聚的评估标准是强度，耦合越弱越好，内聚越强越好；2、所谓过度指的是由于错误理解导致的效果相反的设计；3、耦合指的模块之间的关系，最弱的耦合设计是通过一个主控模块来协调n个模块之间的运作。

还是举一个我举过的例子：客户要求在界面上增加一个字段，你的项目要修改几个地方呢？如果你只要修改项目文档，那么你的开发构架就是最低强度的耦合，而这种设计成熟的开发团队都已经做到了，他们使用开发工具通过项目模型驱动数据库和各层次的代码，而不是直接修改那些代码；4、内聚指的是模块内部的功能，最强的内聚就是功能单一到不能拆分，也就是原子化，5、所以强内聚和弱耦合是相辅相成的，一个良好的设计是由若干个强内聚模块以弱耦合的方式组装起来的―――――――――――――――――――――――――――――――――――――――――――1. 低耦合（Low Coupling）“低耦合”这个词相信大家已经耳熟能详，我们在看spring的书籍、MVC的数据、设计模式的书籍，无处不提到“低耦合、高内聚”，它已经成为软件设计质量的标准之一。

那么什么是低耦合？耦合就是对某元素与其它元素之间的连接、感知和依赖的量度。

这里所说的元素，即可以是功能、对象（类），也可以指系统、子系统、模块。

假如一个元素A去连接元素B，或者通过自己的方法可以感知B，或者当B不存在的时候就不能正常工作，那么就说元素A与元素B耦合。

耦合带来的问题是，当元素B发生变更或不存在时，都将影响元素A的正常工作，影响系统的可维护性和易变更性。

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

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

低耦合就是要求在我们的软件系统中，某元素不要过度依赖于其它元素。

请注意这里的“过度”二字。

系统中低耦合不能过度，比如说我们设计一个类可以不与JDK耦合，这可能吗？除非你不是设计的Java程序。

再比如我设计了一个类，它不与我的系统中的任何类发生耦合。

如果有这样一个类，那么它必然是低内聚（关于内聚的问题我随后讨论）。

耦合与内聚常常是一个矛盾的两个方面。

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

哪些是耦合呢？1．元素B是元素A的属性，或者元素A引用了元素B的实例（这包括元素A调用的某个方法，其参数中包含元素B）。

2．元素A调用了元素B的方法。

3．元素A直接或间接成为元素B的子类。

4．元素A是接口B的实现。

幸运的是，目前已经有大量的框架帮助我们降低我们系统的耦合度。

比如，使用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，如何执行的操作，与我无关。

但是，作为优秀的开发人员，仅仅依靠框架提供的降低软件耦合的方法是远远不够的。

根据我的经验，以下一些问题我们应当引起注意：1）根据可能的变化设计软件我们采用职责驱动设计，设计中尽力做到“低耦合、高内聚”的一个非常重要的前提是，我们的软件是在不断变化的。

如果没有变化我们当然就不用这么费劲了；但是如果有变化，我们希望通过以上的设计，使我们在适应或者更改这样的变化的时候，付出更小的代价。

这里提供了一个非常重要的信息是，我们努力降低耦合的是那些可能发生变更的地方，因为降低耦合是有代价的，是以增加资源耗费和代码复杂度为代价的。

如果系统中某些元素不太可能变更，或者降低耦合所付出的代价太大，我们当然就应当选择耦合。

有一次我试图将我的表现层不依赖于struts，但发现这样的尝试代价太大而失去意义了。

对于软件可能变更的部分，我们应当努力去降低耦合，这就给我们提出一个要求是，在软件设计的时候可以预判日后的变化。

根据以往的经验我认为，一个软件的业务逻辑和采用的技术框架往往是容易变化的2个方面。

客户需求变更是我们软件设计必须考虑的问题。

在RUP的开发过程中，为什么需要将分析设计的过程分为分析模型和设计模型，愚以为，从分析模型到设计模型的过程实际上是系统从满足直接的客户需求到优化系统结构、适应可预见的客户需求变更的一个过程。

这种客户需求的变更不仅仅指对一个客户需求的变更，更是指我们的软件从适应一个客户需求到适应更多客户需求的过程。

另一个方面，现在技术变更之快，EJB、hibernate、spring、ajax，一个一个的技术像走马灯一样从我们脑海中滑过，我们真不知道明天我在用什么。

在这样的情况下，适应变化就是我们最佳的选择。

2）合理的职责划分合理的职责划分，让系统中的对象各司其职，不仅是提高内聚的要求，同时也可以有效地降低耦合。

比如评审计划BUS、评审表BUS、评审报告BUS都需要通过评审计划DAO去查询一些评审计划的数据，如果它们都去直接调用评审计划DAO（如图A），则评审计划BUS、评审表BUS、评审报告BUS三个对象都与评审计划DAO耦合，评审计划DAO一旦变更将与这三个对象都有关。

在这个实例中，实际上评审计划BUS是信息专家（关于信息专家模式我将在后面讨论），评审表BUS和评审报告BUS如果需要获得评审计划的数据，应当向评审计划BUS提出需求，由评审计划BUS提供数据（如图B）。

经过这样的调整，系统的耦合度就降低了。

3）使用接口而不是继承通过对耦合的分析，我们不难发现，继承就是一种耦合。

如果子类A继承了父类B，不论是直接或间接的继承，子类A都必将依赖父类B。

子类A必须使用在存在父类B的环境中，父类B不存在子类A就不能使用，这样将影响子类A的可移植性。

一旦父类B发生任何变更，更改或去掉一个函数名，或者改变一个函数的参数，都将导致子类A不得不变更，甚至重写。

假如父类B的子类数十上百个，甚至贯穿这个项目各个模块，这样的变更是灾难性的。

这种情况最典型的例子是我们现在使用hibernate和spring 设计DAO对象的方式，具体的描述参见我写的《如何在struts + spring + hibernate的框架下构建低耦合高内聚的软件结构》一文。

总之，“低耦合”给软件项目带来的优点是：易于变更、易于重用2. 高内聚（High Cohesion）高内聚是另一个普遍用来评判软件设计质量的标准。

内聚，更为专业的说法叫功能内聚，是对软件系统中元素职责相关性和集中度的度量。

如果元素具有高度相关的职责，除了这些职责内的任务，没有其它过多的工作，那么该元素就具有高内聚性，反之则为低内聚性。

高内聚要求软件系统中的各个元素具有较高的协作性，因为在我们在完成软件需求中的一个功能，可能需要做各种事情，但是具有高内聚性的一个元素，只完成它职责内的事情，而把那些不在它职责内的事情拿去请求别人来完成。