关于软件开发和模块接口设计之一些思考

一个软件系统可以按某种方式划分为各种模块，这里以一般的信息发布系统来说，整体可以划分为两大块：
1、公共模块
      如DAO模块、权限检测、登录信息检测等等，为其他模块作服务的，一般情况下，公共模块之间是不会产生交互行为的，如果非要产生交互性能，那就有可能要合 并公共模块或者转移功能。

2、业务模块
      如用户登录、信息列表展现、信息编辑等等，一般一个业务模块又可以分为
      1）、表现层，或者叫UI层，获取数据、展现、接收输入、校验（有可能不做）
      2）、中间访问层，提供给其他模块调用的接口，同时实现对传入数据有效性校验
      3）、中间层，提供主要的业务逻辑，这个层有可能会和“中间访问层”合并。
      4）、业务数据存储层，主要是处理本业务模块对象

划分模块的原则，以“高内聚、低耦合”为原则，一个模块/子模块，以提供一项功能为根本，避免一个模块提供多个不相关的功能。

一般一个业务模块可能会和多个公共模块、其他业务模块打交道。业务模块与其他模块之间的调用（耦合），尽量设计为可配置的，也就是在不更改代码的情 况下，可以改变耦合双方。

业务模块与业务模块之间尽量避免跨层调用，也避免低阶模块之间产生关联，中间访问层就访问中间访问层。

业务模块和业务模块之间的调用又分为通知型的和反馈型。
1、通知型，就是调用另一个模块，但是不等待其返回结果，这种一般可采用观察者模式来实现
2、反馈型，调用另一个模块，但是需要等待返回结果来决定下一步如何走，采用配置文件的方式来实现

业务模块的中间层如果比较复杂，可以划分成一个装配模块和多个子功能模块来实现，并且采用配置文件来进行装配，故子功能模块之间的接口要设计好。

关于模块功能变化，一般可分为整体功能替换和部分功能块替换。
1、整体功能替换比较好对付，只要接口不变，则可以整体替换，如果接口变了，则需要采用适配器模式来应对
2、部分功能块替换，这个就不太好办，除非预先能预测到哪些可能会变化，采用拦截器的模式来进行替换或更改

被调用模块对于传入的参数应做全面的检查，主要是有效性检查。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/dxymm/archive/2008/05/23/2472482.aspx