Que : 参考教材6.2,结合项目的进程和开发历程,从设计原则的几个方面,对负责设计的模块进行评
估,写出存在的问题和解决方案思考。
设计原则是指把系统功能和行为分解成模块的指导方针。它从两种角度明确了我们应该使用的标准:系统
分解,以及确定在模块中将要提供哪些信息(和隐蔽哪些信息)。设计原则在进行创新性设计时十分有
用,此外它们还有其他用武之地,特别是在设计公约、设计模式和体系结构风格的设计建议基础的形成
过程中。因此,为了合理有效地使用风格和模式,我们必须理解和欣赏它们所隐含的原则,否则,当定
义、修改和拓展模式与风格时,我们极有可能违背了该公约或模式使用和提倡某个原则的初衷。
设计原则的几个方面
模块化
存在的问题及解决方案
接口
存在的问题及解决方案
信息隐藏
存在的问题及解决方案
增量式开发
存在的问题及解决方案
抽象
存在的问题及解决方案
通用性
存在的问题及解决方案
设计原则的几个方面
模块化
模块化,也称作关注点分离 , 是一种把系统中各不相关的部分进行分离的原则,以便于各部分能够独立研
究。关注点可以是功能、数据、特征、任务、性质或者我们想要定义或详细理解的需求以及设计的任何
部分。为了实现模块化设计,我们通过辨析系统不相关的关注点来分解系统,并且把它们放置于各自的
模块中。如果该原则运用得当,每个模块都有自己的唯一目的,并且相对独立于其他模块。使用这种方
法,每个模块理解和开发将会更加简单。同时,模块独立也将使得故障的定位和系统的修改更加简单
(因为对于每一个故障,可疑的模块会减少,且一个模块的变动所影响的其他模块会减少)。
为了确定一个设计是否很好地分离了关注点,我们使用两个概念来度量模块的独立程度:耦合度和内聚
度。
1.耦合度
当两个模块之间有大量依赖关系时,我们就说这两个模块是紧密耦合的(tighly coupled)。松散耦合的
(loosely coupled)模块之间具有某种程度的依赖性,但是它们之间的相互连接比较弱。非耦合的
(uncoupled)模块之间没有任何相互连接,它们之间是完全独立的。
模块之间的依赖方式有很多种。
·一个模块引用另一个模块。模块A可能会调用模块B的操作,因此,模块A为了完成其功能或处理,依赖
于模块B。
·一个模块传递给另一个模块的数据量。模块A可能会传递参数、数组的内容或者数据块给模块B。
·某个模块控制其他模块的数量。模块A可能会将一个控制标记传给B。标记的值会告诉模块B某些资源或
子系统的状态,调用哪个进程,或者是否需要调用某个进程。
实际上,一个系统不可能建立在完全非耦合的模块上。就像一张桌子和几把椅子一样,尽管是互相独立
的,但也可以组成一套餐厅用具。因此,上下文环境可能会间接地耦合那些似乎是非耦合的模块。例
如,如果一个功能中止另一个功能的执行,那么这两个不相关的功能就会进行交车(比如,授权认证功能
会禁止非授权用户取得受保护的服务),因此,没有必要使模块完全独立。只要尽可能地减少模块之间的