设计模式之领航篇高内聚和低耦合

概述内聚和耦合：

        内聚和耦合不是软件工程的专有名词，但是在软件工程衡量软件的标准。但凡用到了这两个词，顿时就感觉了高大上。软件开发过程中遵循高内聚、低耦合的要求，能保证软件的系统的健壮性。内聚指的是独立个体目标很明确，只做一件事。而耦合讲的是关联性和依赖性，发生在多个个体之间。

软件系统的表现：

在软件系统中，内聚和耦合体现在内聚性和耦合性。

• 内聚性又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。
• 耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息

内聚和耦合体现在软件系统在不同粒度上：

从不同的粒度来看，职责越单一，目的明确，内聚性越高，反之则内聚性越低；而个体之间的联系越少，耦合性越低，反之则耦合性越高。

• 方法（函数）：

高内聚：一个类的方法尽量完成一件事，职责单一；

低耦合：避免类之间，方法间的互相调用

• 类：

高内聚：类的职责单一；

低耦合：尽量减少对于其他类方法的调用

• 功能模块：

高内聚：模块功能单一

低耦合：降低和其他模块的交互复杂度，比如接口数量，数据传递

举现实中具体的例子更能明白：

      高内聚，低耦合：比如小霸王游戏机和游戏卡之间的联系，卡坏了可以换张卡，游戏机坏了换个游戏机就好了，毕竟在成本控制内，所以游戏机和卡的耦合性低，另外卡主要是存储游戏内容，游戏机是运行游戏，只负责自己的职责，内聚性高。

      高耦合，低内聚：又比如房子和我们就是一种高耦合性的关系，如果房子出问题了，那么直接导致我们没有休息和居家的环境。房子内包括了我们很多生活场景，洗澡，做饭，卫生间，休息等等，房子是低内聚性。

内聚耦合的分类

耦合的分级

       举例说明现实生活中的例子是为了更好的理解耦合内聚的概念，在软件工程中，耦合是是常见了一种形式。比如一个类，引用了另一个的方法，那么就可以说明这个两个类之间是耦合关系。在软件的执行关于耦合百科上给出来更详细的分类：耦合度从高到低：

• （1） 内容耦合。当一个模块直接修改或操作另一个模块的数据时，或一个模块不通过正常入口而转入另一个模块时，这样的耦合被称为内容耦合。内容耦合是最高程度的耦合，应该避免使用之。

         如：产品模块中有修改订单，物流信息等模块功能的逻辑，那么这就属于内容耦合。内容耦合在系统设计和模块设计等设计初期就应该尽量避免，内容耦合应该很少出现。

• （2） 公共耦合。若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

         比如两个模块都共同访问一个张数据表，一块内存或者缓存数据。

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

        例：将所有的常量都放在一个类中

• （4） 控制耦合 。一个模块通过接口向另一个模块传递一个控制信号，接受信号的模块根据信号值而进行适当的动作，这种耦合被称为控制耦合。

        例子：两个模块之间只有在特定的场景下才会发生联系。比如根据订单状态来进一步确认物流信息或者根据用户状态判断功能是否会可以使用。

• （5） 标记耦合 。若一个模块A通过接口向两个模块B和C传递一个公共参数，那么称模块B和C之间存在一个标记耦合。
• （6） 数据耦合。模块之间通过参数来传递数据，那么被称为数据耦合。数据耦合是最低的一种耦合形式，系统中一般都存在这种类型的耦合，因为为了完成一些有意义的功能，往往需要将某些模块的输出数据作为另一些模块的输入数据。

         例子：常用的数据传递，比如贷款模块经常会用到查看客户信息数据

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

         总体来看，耦合强度是根据两个有关系的对象，当一个对象修改会影响到另一个对象时，耦合度越高，那么影响的范围越大。而在设计开发中，耦合的边界其实是最难定义的，只能定义相对低耦合，没有完全的解藕，独立的个体存在是没有意义的。

内聚的段位：

       首先确定内聚就是一个方法，一个对象（类），甚至是一个模块的内部元素紧密联系，而且尽量做到功能单一和属性单一。在百科中内聚按强度从低到高有以下几种类型：

• （1）偶然内聚：如果一个模块的各成分之间毫无关系，则称为偶然内聚，也就是说模块完成一组任务，这些任务之间的关系松散，实际上没有什么联系。
• （2）逻辑内聚：几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。如一个模块读取各种不同类型外设的输入。尽管逻辑内聚比偶然内聚合理一些，但逻辑内聚的模块各成分在功能上并无关系，即使局部功能的修改有时也会影响全局，因此这类模块的修改也比较困难。

   比如：一个方法中，根据不同的状态，调用不同的方法

• （3）时间内聚：如果一个模块完成的功能必须在同一时间内执行（如系统初始化），但这些功能只是因为时间因素关联在一起，则称为时间内聚。
• （4）通信内聚：如果一个模块的所有成分都操作同一数据集或生成同一数据集，则称为通信内聚。
• （5）顺序内聚：如果一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚。
• （6）功能内聚：模块的所有成分对于完成单一的功能都是必须的，则称为功能内聚。
• （7）信息内聚：模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点。这个模块将根据不同的要求，确定该模块执行哪一个功能。由于这个模块的所有功能都是基于同一个数据结构（符号表），因此，它是一个信息内聚的模块。

         内聚和耦合是两个关联性很强的关系，低耦合必然是要高内聚，反过来，高耦合，其实也会降低内聚性。内聚和耦合这两个方面本身存在依赖关系。

结合实际：

        结合目前项目的做的分布式式拆分，整个系统看似已按照模块功能划分，但实际上由于中心思想并未真正传达到每个coder上，而且对于设计和codeView做的真是有点糟糕，导致各个模块之间耦合度很高。痛定思痛后，经过几轮研讨，对模块有又了重新的划分，对于耦合性较高的模块根据功能特点抽取了一个独立的公共模块，修改模块的关系，对于内容耦合部分，尽量修改为数据耦合。

        一个高内聚，低耦合的项目，模块清晰，每个模块都有自己独立功能和职责，项目易于管理，代码更加清晰而且重复利用率高。目前很多mvc框架极大的帮住了我们项目的解藕。分布式架构体系也是从架构层面的一种解藕，架构中分出不同的节点或者说是模块更清晰的表明职责，解决了单体应用的一损俱损的弊端。如何设计一个高内聚低耦合的项目，首先要从思想上建立一个规范思想，而在实践中确立和实现这种思想。有人说需求是变化莫测的，业务驱动技术，技术也催生业务，相关性的共同成长。当然一个项目不可能一直是完美，这就需要不停打磨，重构再重构，才能更完善。