模块化设计方案-20221114

1模块化编程概述
模块化程序设计是指在程序设计时自顶向下将复杂的任务（父模块）分解为简单的子任务（子模块）。每个小模块完成一个确定的功能，并在这些模块之间既要建立必要的联系，也要避免过多的相互调用。通过模块的互相协作完成整个功能的程序设计方法。
模块化程序设计要求各模块相对独立、功能单一、结构清晰、接口简单。
模块化的基本思路是高内聚低耦合。

2耦合划分
耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。
根据耦合方式，划分为内容耦合，公共耦合，外部耦合，控制耦合，标记耦合，数据耦合，非直接耦合。
2.1内容耦合
定义：
当一个模块直接修改或操作另一个模块的数据时；
一个模块不通过正常入口而转入另一个模块时。
注意：
内容耦合是最高程度的耦合，应该避免使用。

2.2公共耦合
定义：
两个或两个以上的模块共同引用一个全局数据项。
注意：
在具有大量公共耦合的结构中，确定究竟是哪个模块给全局变量赋了一个特定的值是十分困难的。

2.3外部耦合
定义：
一组模块都访问同一全局简单变量，而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息。
注意：
谨慎使用。

2.4控制耦合
定义：
一个模块通过接口向另一个模块传递一个控制信号，接受信号的模块根据信号值而进行适当的动作。

2.5标记耦合
定义：
若一个模块A通过接口向两个模块B和C传递一个公共参数，那么称模块B和C之间存在一个标记耦合。

2.6数据耦合
定义：
模块之间通过参数来传递数据最低的一种耦合形式，系统中一般都存在这种类型的耦合。
需要将某些模块的输出数据作为另一些模块的输入数据。

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

2.8耦合使用限制
内容耦合 不可用/限制使用
公共耦合 限制使用
外部耦合 少用/尽量避免使用
控制耦合 少用/尽量避免使用
标记耦合 少用/尽量避免使用
数据耦合 推荐用
非直接耦合 推荐用
模块设计是影响软件复杂程度和设计质量的一个重要因素。

3模块化的实现
3.1高内聚性
内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。内聚是从功能角度来度量模块内的联系。
一个好的内聚模块应当恰好做一件事，它描述的是模块内的功能联系。
程序讲究的是低耦合，高内聚，同一个模块内的各个元素之间要高度紧密，但是各个模块之间的相互依存度却要不那么紧密。
内聚和耦合是密切相关的。设计内聚的软件模块时，可考虑下列方面：

1. 避免调用同级别其他模块，只考虑使用下层模块；

2. 将依赖集成到本模块内部，使得外部依赖成为内嵌部分；

3. 将可能存在风险的外部依赖模块通过额外的抽象层隔离，使得本模块可以独立于依赖模块而变化；

3.2软件弹性
在对模块所解决的问题的认识高度理解的前提下，抽象出模块的本质，是为软件的弹性设计。
额外的抽象层次会带来性能上的损失，所以设计上应该考虑到性能和弹性的平衡，但在性能问题没有确证之前，弹性优先。弹性带来的问题是复杂性，过于复杂的软件会带来理解和维护上的困难，所以过度的弹性设计也是不可取的。
改进模块弹性的一般的手段有：

1. 采用抽象接口而非具体实例。通过抽象接口实现不同的实例，可提供弹性，而对客户不产生影响；
2. 采用单一职责的简单模块而非复杂庞大的。细粒度的软件单元有更好的适用范围，不同的功能应该使用分离（物理的或逻辑上）的接口，不要在一个模块中提供2个以上的功能服务；
3. 提供可拓展的配置选项，便于后续新增模块的功能且无需修改已有接口。

3.3可移植性
可移植性是指让软件在不同平台上运行的难易程度，不需要任何修改就可以运行的就称为跨平台的。
实际上真正跨平台的软件是不存在的，任何跨平台的软件必须有一个抽象的底层来支撑，这个支撑的部分是需要在不同的平台上重新实现的，也就是软件的需移植部分。因此可以看到，增加一个软件模块的可移植性，需要做两件事：分离不需要移植和需要移植的部分、减小需要移植部分的复杂度以方便移植。
实现软件模块的可移植，首先要分析所有目标平台的异同，确定哪些是可以在所有平台上都支持的，这些就是不需要移植（可移植）的部分。而并非所有平台都支持（只要有一个不支持）的部分则是需要移植的。对模块中无可移植方案的部分，采用接口抽象出一个可移植层，在不同的平台上分别实现此接口，此接口的实现就是整个模块的需要移植部分，在做移植工作时，只要将关注点放在此处。

3.4接口定义
当一个模块不考虑可重用性和可移植性，接口可以定义得不用非常仔细。接口说明可能就以口头约定或项目内部约定为准。这在单一项目内部一般不会造成很大问题，但一旦模块需要重用到其他项目，这种不严谨的方法就会带来诸如语义含混、理解困难、功能定义不明确等问题。因此可重用模块的接口的定义需要比内部使用的模块更严格，一般需要考虑以下方面：
1.接口名称标准化，功能一致性设计，参数和返回结果一致性设计；
2. 对该模块提供的服务的详细描述，模块本身的适用范围详细描述；
3.接口函数的语义说明，包括参数的含义、返回结果、有效范围、异常处理、前提/后置条件等；
4. 提供完整的示例代码演示和说明的文档。

3.5稳定性
函数内部实现稳定性，应注重编程规范、严格检查各种前提/后置条件、编写保护性代码、采用更好的错误处理机制，这些手段都有利于提升模块的功能稳定性。
在设计服务和模块时分析问题域，尽量做到基本框架和接口的设计不做任何修改，只针对新的应用环境做移植和扩展。这种比较稳定的框架设计可以通过在若干个复用过程中反复重构而获得，但需要设计者善于从旧有的设计中提炼总结。参考一些成熟框架也是提升设计稳定性的不错的选择。