软件工程概念：高内聚.低耦合

软件工程概念：高内聚.低耦合

高内聚.低耦合，是软件工程中的概念，是判断软件设计好坏的标准，主要用于程序的面向对象的设计，主要看类的内聚性是否高，耦合度是否低。目的是使程序模块的可重用性、移植性大大增强。通常程序结构中各模块的内聚程度越高，模块间的耦合程度就越低。内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事，它描述的是模块内的功能联系；耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。

• 中文名：高内聚低耦合
• 外文名：High cohesion & Low coupling
• 范 围：计算机科学
• 应 用：程序的面向对象
• 设计目的：增强可重用性、移植性
• 组 成：内聚、耦合

1、简介

在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分模块的一个准则是高内聚低耦合。

• 从模块粒度来看，高内聚：尽可能类的每个成员方法只完成一件事（最大限度的聚合）； 低耦合：减少类内部，一个成员方法调用另一个成员方法。
• 从类角度来看， 高内聚低耦合：减少类内部，对其他类的调用；从功能块来看 高内聚低耦合：减少模块之间的交互复杂度（接口数量，参数数据）即横向：类与类之间、模块与模块之间；纵向：层次之间；尽可能，内容内聚，数据耦合。

降低耦合度的方法：

• 1、少使用类的继承，多用接口隐藏实现的细节。 Java面向对象编程引入接口除了支持多态外， 隐藏实现细节也是其中一个目的。
• 2、模块的功能化分尽可能的单一，道理也很简单，功能单一的模块供其它模块调用的机会就少。（其实这是高内聚的一种说法，高内聚低耦合一般同时出现）。
• 3、遵循一个定义只在一个地方出现。
• 4、少使用全局变量。
• 5、类属性和方法的声明少用public，多用private关键字。
• 6、多用设计模式，比如采用MVC的设计模式就可以降低界面与业务逻辑的耦合度。
• 7、尽量不用“硬编码”的方式写程序，同时也尽量避免直接用SQL语句操作数据库。
• 8、最后当然就是避免直接操作或调用其它模块或类（内容耦合）；如果模块间必须存在耦合，原则上尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，避免使用内容耦合。

增强内聚度方法：

• 1、模块只对外暴露最小限度的接口，形成最低的依赖关系。
• 2、只要对外接口不变，模块内部的修改，就不得影响其他模块。
• 3、删除一个模块，应当只影响有依赖关系的其他模块，而不应该影响其他无关部分。

2、架构设计

• 架构是指可以预制和重构的软件框架结构。
• 普遍指通过某种特定平台，而达到完成整体软件的功能。
• 架构设计是指对软件、硬件、网络、运营、政策等软件设计中的需求和要素进行决策，主要包括体系结构设计和各个层的模块设计。
• 架构设计目标有个能够最大化的重用。
• 首先，要在架构的设计中灵活地使用各种共享的，特别是开源的框架技术因为共享的架构可以方便开发组分解问题，从而对项目中的功能模块分为需要内部解决和使用已有外部服务两类，避免了重复开发实现。
• 其次，尽量使用成熟的框架。由于服务器端软件系统的开发，涉及的知识、内容、要解决的技术问题很多，在某些方面使用第三方成熟的框架，相当于让别人帮助开发者完成了一些基础性的工作，此时开发者只需要集中精力完成系统业务逻辑的设计和实现。使软件系统实现可扩展性在技术上灵活地使用各种架构模式和代码设计模式，并且在使用代码设计模式的同时，使用其所提倡的面向接口编程，会对软件系统的可扩展性和可移植性的提高有所帮助。
• 希望能够设计出“高内聚、低耦合”的应用系统。
• 这是架构设计最主要的目标，实现系统的高内聚、低耦合遵从以下原则：
  • 利用分层架构实现系统在纵向上的低藕合；
  • 利用开源框架进一步确保纵向分层的具体实现；
  • 按照功能划分子系统来实现横向上的低偶合；
  • 利用包结构确保横向上低耦合的具体实现 。

3、内聚与耦合

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

3.1 内聚 (模块内部，粒度可大可小, 可以是函数, 类, 功能块等)

内聚：故名思议，表示内部间聚集、关联的程度，那么高内聚就是指要高度的聚集和关联。高内聚是指类与类之间的关系而定，高，意思是他们之间的关系要简单明了，不要有很强的关系，不然，运行起来就会出问题。一个类的运行影响到其他的类。由于高内聚具备可靠性，可重用性，可读性等优点，模块设计推荐采用高内聚。内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系。

• 偶然内聚：一个模块内的各处理元素之间没有任何联系，只是偶然地被凑到一起。这种模块也称为巧合内聚，内聚程度最低。
• 逻辑内聚：这种模块把几种相关的功能组合在一起， 每次被调用时，由传送给模块参数来确定该模块应完成哪一种功能 。
• 时间内聚：把需要同时执行的动作组合在一起形成的模块称为时间内聚模块。
• 过程内聚：构件或者操作的组合方式是，允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。简单的说就是如果一个模块内的处理元素是相关的，而且必须以特定次序执行则称为过程内聚。例如某要完成登录的功能，前一个功能判断网络状态，后一个执行登录操作，显然是按照特定次序执行的。
• 通信内聚：指模块内所有处理元素都在同一个数据结构上操作或所有处理功能都通过公用数据而发生关联（有时称之为信息内聚）。即指模块内各个组成部分都使用相同的数据结构或产生相同的数据结构。
• 顺序内聚：一个模块中各个处理元素和同一个功能密切相关，而且这些处理必须顺序执行，通常前一个处理元素的输出时后一个处理元素的输入。例如某要完成获取订单信息的功能，前一个功能获取用户信息，后一个执行计算均价操作，显然该模块内两部分紧密关联。顺序内聚的内聚度比较高，但缺点是不如功能内聚易于维护。
• 功能内聚：模块内所有元素的各个组成部分全部都为完成同一个功能而存在，共同完成一个单一的功能，模块已不可再分。即模块仅包括为完成某个功能所必须的所有成分，这些成分紧密联系、缺一不可。

模块内部的元素, 关联性越强, 则内聚越高, 模块单一性更强。 一个模块应当尽可能独立完成某个功能, 如果有各种场景需要被引入到当前模块, 代码质量将变得非常脆弱, 这种情况建议拆分为多个模块。低内聚的模块代码, 不管是维护, 扩展还是重构都相当麻烦, 难以下手

3.2 耦合 (模块之间的关系)

耦合：是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。 模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。降低模块间的耦合度能减少模块间的影响，防止对某一模块修改所引起的“牵一发动全身”的水波效应，保证系统设计顺利进行。 耦合度就是某模块（类）与其它模块（类）之间的关联、感知和依赖的程度，是衡量代码独立性的一个指标。

• 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。耦合度最弱，模块独立性最强。
• 数据耦合：调用模块和被调用模块之间只传递简单的数据项参数。相当于高级语言中的值传递。
• 标记耦合：调用模块和被调用模块之间传递数据结构而不是简单数据，同时也称作特征耦合。表就和的模块间传递的不是简单变量，而是像高级语言中的数据名、记录名和文件名等数据结果，这些名字即为标记，其实传递的是地址。
• 控制耦合：模块之间传递的不是数据信息，而是控制信息例如标志、开关量等，一个模块控制了另一个模块的功能。
• 外部耦合：一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为外部耦合。
• 公共耦合：一组模块都访问同一个全局数据结构，则称之为公共耦合。公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。如果模块只是向公共数据环境输入数据，或是只从公共数据环境取出数据，这属于比较松散的公共耦合；如果模块既向公共数据环境输入数据又从公共数据环境取出数据，这属于较紧密的公共耦合。
  • 公共耦合会引起以下问题：
    • 1. 无法控制各个模块对公共数据的存取，严重影响了软件模块的可靠性和适应性。
    • 2. 使软件的可维护性变差。若一个模块修改了公共数据，则会影响相关模块。
    • 3. 降低了软件的可理解性。不容易清楚知道哪些数据被哪些模块所共享，排错困难。
  • 一般地，仅当模块间共享的数据很多且通过参数传递很不方便时，才使用公共耦合。
• 内容耦合：一个模块直接访问另一模块的内容，则称这两个模块为内容耦合。
  • 若在程序中出现下列情况之一，则说明两个模块之间发生了内容耦合：
    • 1. 一个模块直接访问另一个模块的内部数据。
    • 2. 一个模块不通过正常入口而直接转入到另一个模块的内部。
    • 3. 两个模块有一部分代码重叠（该部分代码具有一定的独立功能）。
    • 4. 一个模块有多个入口。
  • 内容耦合可能在汇编语言中出现。大多数高级语言都已设计成不允许出现内容耦合。这种耦合的耦合性最强，模块独立性最弱。

模块之间存在依赖, 导致改动可能会互相影响, 关系越紧密, 耦合越强, 模块独立性越差。比如模块A直接操作了模块B中数据, 则视为强耦合, 若A只是通过数据与模块B交互, 则视为弱耦合。独立的模块便于扩展, 维护, 写单元测试, 如果模块之间重重依赖, 会极大降低开发效率. 

创建时间：2021.09.06　　更新时间：