模块独立性
模块化设计是指将软件分解为多个独立模块，不同的模块具有不同的功能和职责。每个模块可以独立的进行开发、测试，最后组装成完整的软件。
模块独立性是指软件系统中每个模块只涉及软件要求的子功能，而与软件系统中其他模块的接口是简单的。例如如果一个模块只具有单一功能且与其他模块没有太多的联系，那么称此模块具有模块独立性。
具有高内聚低耦合的模块，才是模块独立性比较强的模块
耦合
• 耦合性是程序结构中各个模块之间相互关联的度量
• 它取决于各个模块之间接口的复杂程度、调用模块的方式以及那些信息通过接口
| 低 耦合性 高 | ||||||
| 非直接耦合 |
数据耦合 |
标记耦合 |
控制耦合 |
外部耦合 |
公共耦合 |
内容耦合 |
| 高 功能独立性 低 | ||||||
非直接耦合(Nondirect Coupling)
• 两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。
• 非直接耦合的耦合性最低，模块独立性最强。
数据耦合 (Data Coupling)
• 一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的
标记耦合 (Stamp Coupling)
• 一组模块通过参数表传递记录信息，就是标记耦合
• 这个记录是某一数据结构的子结构，而不是简单变量
控制耦合 (Control Coupling）
• 如果一个模块通过传送开关、标志、名字等控制参数，明显地控制选择另一模块的功能，就是控制耦合
外部耦合（External Coupling）
• 一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，
则称之为外部耦合
公共耦合（Common Coupling）
• 若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合
内容耦合 (Content Coupling)
• 如果发生下列情形，模块之间就是内容耦合:
– 一个模块直接访问另一个模块的内部数据
– 一个模块不通过正常入口转到另一模块内部
– 两个模块有一部分程序代码重迭(只可能出现在汇编语言中)
– 一个模块有多个入口
内聚
• 模块内聚性越强，功能独立性越好，对于形成的模块结构有比较好的作用。
• 要求模块结构达到高内聚，低耦合。
| 高 内聚性 低 | ||||||
| 功能内聚 |
信息内聚 |
通信内聚 |
过程内聚 |
时间内聚 |
逻辑内聚 |
巧合内聚 |
| 高 功能独立性 低 | ||||||
功能内聚 (Functional Cohesion)
• 一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说该模块中所有部分都是为了完成
一项具体功能而协同工作，紧密联系，不可分割的，则称该模块为功能内聚模块
• 功能内聚模块的内聚最高，功能独立性最强
信息内聚 (Informational Cohesion)
• 完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点
通信内聚(Communication Cohesion)
• 如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，则称之为通信内聚模块
• 通常，通信内聚模块是通过数据流图来定义的
过程内聚（Procedural Cohesion）
• 使用流程图做为工具设计程序时，如果流程图太大，可以把流程图中的某一部分划出组成模块，就得到过
程内聚模块
– 例如，把流程图中的循环部分、判定部分、计算部分分成三个模块，这三个模块都是过程内聚模块。
时间内聚（Classical Cohesion）
• 时间内聚又称为经典内聚
• 大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行
– 例如，初始化模块和终止模块就是时间内聚模块。
逻辑内聚（Logical Cohesion）
• 这种模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪
一种功能。
巧合内聚（Coincidental Cohesion）
• 当几个模块内正好有一段代码是相同的，将它们抽取出来形成单独的模块，即巧合内聚模块。这种模块没
有独立功能，各部分之间没有联系，或联系很松散。
面向对象设计原则
里氏替换原则（LSP： TheLiskov Substitution Principle）
•是指凡是父类可以出现的地方，子类都可以出现
开闭原则（OCP： TheOpen-Close Principle）
•是指一个软件实体应该对扩展开发，对修改关闭，即在不修改源代码的基础上扩展一个系统的行为
单一职责原则（SRP： TheSingle Responsibility Principle）
•是指在软件系统中，一个类应该尽量只有一个引起它发生变化的原因
依赖倒转原则（DIP： TheDependency Inversion Principle）
•是指抽象不应该依赖于具体，而是具体依赖于抽象
接口隔离原则（ISP： TheInterface Segregation Principle）
•是应该提供小而专的接口，而不是大而全的接口
组合/聚合原则（FCOI： Favor Composition OverInheritance）
•是指优先使用组合/聚合进行复用，而不是继承
迪米特原则（LoD： Law ofDemeter）
•是指一个软件实体应当尽可能少的与其他实体发生相互作用