《敏捷软件开发原则模式与实践读书笔记3》由会员分享，可在线阅读，更多相关《敏捷软件开发原则模式与实践读书笔记3（11页珍藏版）》请在金锄头文库上搜索。
1、敏捷软件开发 原则、模式与实践读书笔记3敏捷软件开发：原则、模式与实践读书笔记32010年04月01日星期四17：20第18章薪水支付案例研究：第一次迭代开始第18章薪水支付案例研究：第一次迭代开始-18.1介绍本章使用的用户素材都是很简单的，这是初期迭代的特征，仅提供用户所需商业价值中最小的部分。本章进行快速的分析和会话设计，这通常发生在一次迭代开始时。下一章进行实际的设计工作，完成但愿测试和实现。第18章薪水支付案例研究：第一次迭代开始-18.1.1规格说明描述在和客户交谈时关于第一次迭代中的素材的记录。根据用户素材，可以首先生成数据库模式(database schema)，不过在使用这种
2、方法产生的应用程序中，数据库成为了关注的中心。数据库是实现细节，应该尽可能推迟考虑数据库。有太多的应用程序，之所以和数据库绑定在一起而无法分开，就是因为一开始设计时就把数据库考虑在内。请记住，抽象的定义，本质部分的放大，无关紧要部分的祛除。在项目的当前阶段，数据库是无关紧要的；它只不过是用来存储和访问数据的技术而已。第18章薪水支付案例研究：第一次迭代开始-18.2基于用例的分析先来考虑一下系统行为，而不是系统的数据。一种捕获、分析系统行为的方法是创建用例(user case)。按照最初Jacobson的描述，用例和XP中的用户素材的概念非常相似。用例就是更详细一点的用户素材。一旦在迭代中要实
3、现当前该用户素材，这种详细是合适的。在进行用例分析时，我们关注用户素材和验收测试，以找出系统的用户会执行的操作种类。接着我们会努力弄清楚系统怎样去响应这些操作。列举了7个本地迭代选取的用户素材。下面把用户素材转化为详细的用例。只要有助于考虑出每个素材的代码设计即可，不要陷入过多的细节。第18章薪水支付案例研究：第一次迭代开始-18.2.1增加雇员根据增加雇员用例分析操作方面：利用COMMAND模式，创建AddEmployeeTransaction基类，三个派生类AddHourlyEmployeeTransaction、AddSalariedEmployeeTransaction、AddComm
4、issionedEmployeeTransaction。把每项工作划分到自己的类中，遵循SRP原则。也可以把所有代码放到一个模块中，这样就减少了类的数量，系统也更简单，但使所有的操作代码集中于一个模块造成庞大切可能出错的模块。对象模型：抵制住记录规划或字段结构等数据库倾向的诱惑，从对象模型的角度思考：图18.2：Employee基类，3个派生类HourlyEmployee、CommissionedEmployee、SalariedEmployee。第18章薪水支付案例研究：第一次迭代开始-18.2.2删除雇员描述删除雇员用例。第18章薪水支付案例研究：第一次迭代开始-18.2.3登记时间卡描述
5、等级时间卡用例。用例表示，一些操作只能应用于某类雇员。这加强了不同类的雇员应该使用不同的类表的观点。第18章薪水支付案例研究：第一次迭代开始-18.2.4登记销售凭条用例4：登记销售凭条。与用例3类似，暗示一些操作只能应用于某类雇员。第18章薪水支付案例研究：第一次迭代开始-18.2.5登记协会服务费用例5：登记协会服务费协会会员有自己的成员标识。第18章薪水支付案例研究：第一次迭代开始-18.2.6更改雇员明细用例6：更改雇员明细该用例具有启迪性。由于可以把雇员从钟点工，修改为带薪雇员。显然图18.2并不合适。在薪水计算中，使用STRATEGY模式也许更恰当。图18.6：Employee类持
6、有一个名为PaymentClassification的对象，这个对象具有HourlyClassification、SalariedClassification、CommissionedClassification。HourlyClassification含有Timecard对象列表。CommissionedClassification含有SalesReceipt。都是采用了组合(composition)方式使用STRATEGY实现支付方式的改变。对于协会成员使用了NULL OBJECT模式。这些模式的使用使得系统很好的符合了OCP，Employee对于支付方式、支付类别、协会从属关系的变化都是
7、封闭的。这样，可以在不影响Employee的情况下，向系统增加新的支付方式，支付类别以及协会从属关系。图18.6成为了我们的核心模型，(core model)或者架构(architecture)。是薪水支付系统所有事情的核心。在薪水支付案例中的其他类和设计，相对于这个基础结构而言都是次要的。当然，这个结构也会和其他部分仪一起演化。第18章薪水支付案例研究：第一次迭代开始-18.2.7发薪日用例7现在运行薪水支付应用程序将薪水计算的任务交付给PaymentClassification。第18章薪水支付案例研究：第一次迭代开始-18.3反思：我们学到了什么用简单的用力分析可以提供丰富以及系统设计的
8、洞察力。图18.6-18.10就是通过思考这些用例得到的，更确切地说，是思考行为得到的。第18章薪水支付案例研究：第一次迭代开始-18.4找出潜在的抽象为了有效的OCP，必须搜寻出隐藏于应用背后的对象。应用需求，甚至用例，不会表达，这些抽象。需求和用例太关注细节以至于不能潜在抽象的一般性。SLS：提炼公用组件也是这个道理。第18章薪水支付案例研究：第一次迭代开始-18.4.1支付薪水时间表抽象支付时间是非常多边的。过度依赖工具和过程低估智力和经验都是灾难的源泉。结果是：增加PaymentSchedule，以及其3个子类对应已知的三种方式。Employee包含了PaymentSchedule。第
9、18章薪水支付案例研究：第一次迭代开始-18.4.2支付方式支付方式的抽象已经从18.6图中表现出来了，他就是PayMethod。第18章薪水支付案例研究：第一次迭代开始-18.4.3从属关系某一雇员可能属于某一协会，但实际是一个雇员可能属于多个协会。结果是Employe持有Affiliation的列表，如果不属于任何协会Affiliation列表，置空即可，不必使用NULL OBJECT模式了。第18章薪水支付案例研究：第一次迭代开始-18.5结论在一次迭代开始，开发团队通常会聚集在一个白板前，一起思考需要实现的用户素材。这类快速设计会话持续时间会小于1小时。也许会产生UML，但最终这些UM
10、L不会留在白板上。会话的目的就是发起思考活动，并为开发人员提供一个公共的，可依据其展开工作的智力模型，而不是为了确定设计。本章就是一个快速设计会话的原原本本的例子。第19章薪水支付案例研究：实现本章以微笑增量的方式来创建代码。UML图用于展现我们的想法，为交流提供媒介。图19.1，使用名为Transaction的抽象基类代表操作。采用COMMAND模式，具有execute方法。第19章薪水支付案例研究：实现-19.1增加雇员图19.2，描述AddEmployeeTransaction的上下结构。像往常一样，使用测试优先的方法编写代码：程序19.1.第19章薪水支付案例研究：实现-19.1.1薪
11、水支付系统数据库AddEmployeeTransaction类使用了PayrollDatabase的类，PayrollDatabase中保存了一empID为键值的Dictionary。PayrollDatabase是FACADE模式的列子。程序19.3，19.4该实现是为了帮助通过最初的测试用例。一般而言，我们认为数据库实现是细节。应该尽可能推迟细节的设计决策。不管这个特定的数据库，是RDBMS、平面文件(flat file)、或者OODBMS实现。现在仅对API感兴趣，随后会发现有关数据库的合适实现。推进有关数据库的细节，是一项不常见的、但却很值得的实践。直到对需求有了更多的了解，才进行有关
12、的数据库的决策。通过等待，避免把过多的基础结构放入数据库中。我们仅仅实现刚好实现满足应用程序功能的数据库。第19章薪水支付案例研究：实现-19.1.2使用TEMPLATE METHOD模式来增加雇员图19.4，展示了增加雇员的动态模型。图中，AddEmployeeTransaction向自己发送了一条消息(SLS：调用)，其子类实现了这条消息(SLS：方法)。这是一个TEMPLATE METHOD模式的应用。程序19.5、19.6是AddEmployeeTransaction的头文件和cpp文件。程序19.7、19.8是AddSalariedTransaction的头文件和cpp文件。第19章
13、薪水支付案例研究：实现-19.2删除雇员图19.5、19.6中展现了删除雇员操作的静态，动态实现。主要类为DeleteEmployeeTransaction。第19章薪水支付案例研究：实现-19.2.1全局变量对于全局变量GpayrollDatabase，数十年来，教科书和教师一直有好的理由不鼓励使用全局变量。在本例中，使用SINGLETON或MINISTATE模式具有不必要复杂性的臭味。但并不认为全局变量本身是邪恶的，本例中就很适合使用。第19章薪水支付案例研究：实现-19.3时间卡、销售凭条以及服务费用图19.7、19.8展示了时间卡操作的静态和动态结构。主要思路：从PayrollData
14、base得到Employee-PaymentClassification，将TimeCard放入其中。将TimeCard放入PaymentClassification中时，需要使用，dynamic_cast操作符。程序19.12为测试用例。程序19.13为TimeCard的实现，目前就是一个数据类。程序19.13为TimeCardTransaction类的实现。其中使用了字符串异常。这不是一个好的长期实践，在抛出异常时很容易出现泄漏内存或资源的代码，要注意。图19.9、19.10展示了向应支付薪水的雇员中登记销售凭条的设计。图19.11、19.12展示了向协会成员等级服务费用的设计。程序19.
15、16为测试用例，第19章薪水支付案例研究：实现-19.3.1代码与UML画UML而没有验证它的代码是很危险的。代码可以告诉你UML不能告诉你的设计内容。在UML中放入不需要的内容，也许总有一天会用上，但在用上之前必须要不断的维护。所以关于员工的会员，我们从对象列表改会NULL OBJECT模式。程序19.17、19.18展示了使用NULL OBJECT模式的ServiceChangeTransaction类的实现。第19章薪水支付案例研究：实现-19.4更改雇员属性图19.3、19.4展示了修改雇员属性的动态结构，SLS：我觉得作者的设计，一直是按照一个操作一个类的方式设计的，如果这样的设计放
16、到很多系统中，肯定会有类爆炸的问题。难道作者没有发现这个问题?图19.15、19.16、19.17展示了改动的动态模型。使用TEMPLATE METHOD模式，从PayrollDatabase取Employee对象的操作在基类中，然后调用自己的change函数，在子类中实现change函数。程序19.19展示了ChangeNameTransaction的测试用例。程序19.20、19.21展示了抽象基类ChangeEmployeeTransaction的实现。一个明显的TEMPLATE METHOD模式。程序19.22、19.23展示了ChangeNameTransaction类的实现。TEMPLATE METHOD模式的另一半。第19章薪水支付案例研究：实现-19.4.1更改雇员类别图19.18-19.21展示了ChangeClassificationTransaction的动态行为。又一个TEMPLATE METHOD模式。程序19.24展示了ChangeHourlyTransaction的
