敏捷软件开发：原则、模式与实践的学习笔记

第四部分   打包薪水支付案例

20．包的设计原则

 

通常以包的形式，对应用程序从高层次进行组织。这里从两个方面考虑：一方面是根据什么指导原则把类划分到包中，另一方面是怎么处理包之间的相互关系。

 

包的粒度：包的内聚性原则。根据自底向上的观点对类进行划分。

CRP是共同重用原则，告诉我们更多的是，什么类不应该放到一起。

SRP->CCP，一个包不应该包含多个变化的原因。

 

晨后综合征：参与项目开发的人第二天早上会发现自己原本完成的工作出现了问题，这是因为关联的其他人的模块发生了改动带来的影响。因此应尽可能的保证包之间的稳定。

包的稳定性：包的耦合性原则。

每周构建随着系统规模扩大，集成时间越来越长。

消除依赖性，理想的包依赖图是有向无环图(DAG)。通过DIP,消除依赖环。

包的依赖关系结构是和系统的逻辑设计一起发展的。

 

       稳定依赖原则：朝着稳定的方向进行依赖。稳定性是指不容易更改。遵循SDP，保证经常变化的包不会被稳定的包所依赖，导致难以更改。

       稳定性度量：        包的责任（包的输入耦合度）和依赖性（包的输出耦合度）。

 

       稳定抽象原则：包的抽象方向应该与稳定方向一致。SAP和SDP保证了DIP,最终达到依赖于抽象。

 

 

      

21．Factory模式

有时违反DIP也是无害的。当具体类稳定时，不会引发问题。但当具体类容易变化时，就会产生麻烦。

Factory模式允许只依赖抽象的接口创建出具体类。

Shape 工厂

Factory模式的一个缺点，当增加新的派生类时，Factory里需要增加相应方法，存在一个依赖关系环。解决方法：牺牲一点类型安全性，用if/else链对传入的参数进行判断。

 

对测试支架使用对象工厂

欺骗一个对象的创建者（spoof）

 

22．薪水支付案例研究

面向对象设计原则之一：避免高发布率。

从简单的包开始，必要的时候再增加包结构。

基于操作的划分比基于功能的划分重要

使用对象工厂使具体包位于主程序附近

第五部分   气象站案例研究

27．案例研究：气象站

第六部分 ETS框架

29．STATE模式

STD：状态迁移图

STT：状态迁移表

 

实现技术：

1．使用嵌套的switch/case

2．表驱动方法：解释迁移表

 

STATE模式：

既有switch/case的效率，又有迁移表的灵活

STATE模式

 

STRATEGY模式和STATE模式

STATE模式中派生类持有上下文的引用

分离了逻辑和动作，逻辑在派生类中，动作在上下文中

 

GUI控制器和分布式处理中都可以用上STATE模式

30．ETS框架

编写一次循环

这种做法的优雅之处在于遍历数据结构的循环被放置在一个地方。

TEMPLATE METHOD是通过继承，STRATEGY是通过委托实现。

为什么选择了TEMPLATE METHOD,因为更简单，数据结构并不会频繁改变，编译所有的继承类时间并不长。

 

即使TEMPLATE METHOD模式中继承关系的使用导致设计中的耦合关系更紧一些，并且即使STRATEGY模式比TEMPLATE METHOD模式更好地符合DIP，最后还是觉得不值得创建两个额外的类去实现STRATEGY模式。

 

要交付的应用程序的公共需求

命令窗口中触发的命令都需要和任务窗口进行大量的交互。

 

事件转换成动作运用STATE模式

使用SMC,可以简单地创建出事件处理需要的状态机代码。其中SMC（状态机编译器）是一个免费软件，可以到 http://www.objectmentor.com下载。

 

TASKMASTER构架