如何将系统模块化

摘要：

《如何将系统模块化》一文阐述了系统模块化的重要性，应遵守的高内聚低耦合的原则，以及常用大粒度的划分方法,并对一些原则进行了相应的补充说明。当然要编写出高质量的软件程序，还需要理清需求，把控好设计，使用恰当的技术，处理好业务逻辑，编写高质量的代码，更需要一遍又一遍的重构改进

废话：很久没有写代码了，也很久没有从事软件开发设计的工作，想想之前设计编写代码日以夜继的日子，还是蛮怀念的~最近在带领人员做一些项目的时候，发现开发出来的软件可改进的空间还是蛮大的，如系统模块划分不清，代码编写质量不高等，当然要编写出一个好的程序不是一件容易的事，需要理清需求，把控好设计，使用恰当的技术，处理好业务逻辑，编写高质量的代码，更需要一遍又一遍的重构改进.

当然追求完美，本身就不完美，绝大部分的情况下，也没有充足的时间允许这样做。不过追求完美的心态还是值得肯定的，不然也没有动力改善自身的技能水平，若能有经验的长者加以引导，少走一些弯路，那对人员的成长大有裨益，当然修行还是靠自身。提升自我，正视自我的不足，也会使得人员备感压力，值得欣慰的事，人员还是挺上进努力的，只是任重道远，简言之，革命尚未成功，同志还需努力！

扯远了，回正题，这里先将软件需求以及代码编写质量的内容暂且置于一旁，这些也非三言两语所能说完，况且自身的修为也不够，这里还是集中精力重点说下系统模块化的划分，顺便也借此温故而知新：

 

系统模块化的重要性：

对于绝大部分的项目而言，系统模块化的重要性不言而喻。一个良好的模块划分可以使得系统，具有以下好处：

1． 更高的可靠性，将系统划分成一个个相对独立的模块，有利于开发人员缩小问题域，集中精力解决单一模块存在的各种问题异常，通过局部改进，最终使得软件的可靠性得以改善.

2． 更稳定的结构，遵循高内聚低耦合，将不同领域的模块分隔开来，并保留简单高效严谨的通信接口，能够有效的避免一个功能模块的问题扩散到另一模块

3． 更强的维护性，良好的结构划分，清晰的代码逻辑，具有更好的可读性，便于开发人员理解维护

4． 代码可重用性更强，系统模块化能够使开发人员更好的理清业务逻辑结构，提取出公共的模块，从而提高代码的可重用性

5． 缩短项目开发周期，采取分而治之的策略，分块解决问题，使得问题更易于处理，且更加可控，减少问题处理反复所投入的不必要时间

 

系统模块化的原则

根据软件设计的模块化，抽象，信息隐藏和局部分等原则，可以得出模块化的独立性概念。所谓模块独立性，即模块内部逻辑相对独立完整单一，模块间联系尽可能少，具体表现为高内聚低耦合。符合高内聚低耦合的模块，通常功能完整独立，数据接口简单，程序易于实现，易于理解维护，同时也限制了错误的作用范围，使错误易于排除，因而可使软件开发速度快，质量高。

内聚度

内聚度是指模块内部的联系紧密程度，联系越紧，则内聚度越高，模块独立性越强，系统越易于理解维护。具有良好内聚度的模块应能较好的满足于信息局部化的原则，功能完整单一。同时，模块的高内聚必然导致模块的低耦合度。理想的情况是：一个模块只使用局部数据变量，完成一个功能。

按由弱到强的顺序，模块的内聚度可分为以下几类：

1． 偶然内聚：块内的各个任务没有什么有意义的联系，仅于偶然位于同块，若非时空限制，不应使用

2． 逻辑内聚：一个模块完成的任务在逻辑上属于相同或相似的一类(如根据参数不同，模块输出多种结果)，但这种内聚的模块存在一些致命的问题，如修改困难，模块内部改动，需要考虑到其它模块的调用影响；模块内部需要判别调用者，使得模块外部间的联系增加；内部判断陷阱的产生以及装载整块所带来的性能下降等等

3． 时间内聚：是指一个模块中包含的任务需要在同一时间内执行（如初始化，结束等所需的操作）

4． 过程内聚：一个模块内的各个处理元素是相关的，而且必须按固定的次序执行，表现为有次序的流程，面向过程化的思维更多的是采用这种方式进行模块/函数的划分

5． 通信内聚：一个模块中的各处理元素 需要引用共同的数据

6． 顺序内聚：一相模块内各处理元素关系密切，必须按规定的处理次序顺序执行，后执行的语句/段往往依赖先执行的语句/段

7． 功能内聚：模块仅完成一个单一的功能，且该模块的所有部分是实现这一功能所必须的，没有多余的语句。功能内聚是内聚度最高的一种模块类型，结构紧凑，逻辑清晰，易于理解，便于维护，可靠性强，稳定性高，因功能单一，复用性高。在划分模块的时候，应追求此类型。

耦合度

耦合度是从模块外部考察模块的独立性程度，用来衡量多个模块间的相互联系，一般情况下耦合度应从以下三方面考虑：

耦合内容的数量：模块间发生联系的数据和代码的多少，多则高，少则低；

模块的调用方式：模块间代码数据共享的方式，直接调用，依赖调用，加载调用等

模块间的耦合类型：耦合类型有以下几种方式：

独立耦合，模块间彼此独立，没有直接联系，且属于同个软件系统或隶属同一上层模块

数据耦合，模块间彼此交互数据，接受返回值，传递数据参数，通常应保持模块间的关系为数据耦合

控制耦合，模块间传递的是控制参数而非数据参数，用于控制另一模块的处理逻辑，这说明另一模块内部存在多个并列的逻辑路径，通过提高被调用模块的内聚性，可以彻底的去除这种联系。由于增加了设计理解的复杂度，应避免使用该耦合方式。

公共耦合，又称公共环境耦合或数据区域耦合。若模块间对同一数据区域进行存取操作，则模块间的关系为公共耦合。

内容耦合，一个模块直接访问另一模块内部代码或数据，出现内容耦合。内容耦合严重破坏了模块的独立性和系统结构化，代码互相纠缠，运行错综复杂，应完全不使用内容耦合

系统模块化方法

以下列举常见的大粒度模块划分方法

基于需求功能划分：根据用户需求归类的不同，对模块进行大粒度的划分，如用户管理模块，订单流程模块等

基于系统层次划分：根据模块上下级，同层类别的关系进行模块划分，如展现层，业务层，数据层等

基于专业领域划分：根据解决的问题域的不同，对模块进行划分，如人机交互领域，数据库领域，网络通信领域，数据加解密，图形图像等