读书笔记：敏捷软件开发原则、模式与实践.zip

# 薪水支付案例 ## 第一次迭代开始 - 需求 - 有些雇员是钟点工。会按照他们雇员记录中每小时报酬字段的值对他们进行支付。他们每天会提交工作时间卡，其中记录了日期以及工作小时数。如果他们每天工作超过 8 小时，那么超过的部分会按照正常报酬的 1.5 倍进行支付。每周五对他们进行支付。 - 有些雇员完全以月薪进行支付。每个月的最后一个工作日对他们进行支付。在他们的雇员记录中有一个月薪字段。 - 同时，对一些带薪雇员，会根据他们的销售情况，支付给他们一定数量的酬金。他们会提交销售凭条，其中记录了销售的日期和数量。在他们的雇员记录中有一个酬金报酬字段。每隔一周的周五对他们进行支付。 - 雇员可以选择支付方式。可以选择把支付支票邮寄到他们指定的邮政地址；也可以把支票保存在出纳人员那里随时支取；或者要求将薪水直接存入他们指定的银行账户； - 一些雇员会加入协会。在他们的雇员记录中有一个每周应付款项字段。这些应付款必须要从他们的薪水中扣除。协会有时也会针对单个协会成员征收服务费用。协会每周会提交这些服务费用，服务费用保修要从相应雇员的下个月的薪水总额中扣除。 - 薪水支付程序每个工作日运行一次，并在当天为相应的雇员进行支付。系统会被告知雇员的支付日期，这样它会计算从雇员上次支付日期到规定的本次支付日期间应支付的数额。 - 数据库是实现细节！ - 应该尽可能地推迟考虑数据库。有太多的应用程序之所以和数据库绑定在一起而无法分离，就是因为一开始设计时就把数据库考虑在内了； - 请记住抽象的定义：本质部分的放大，无关紧要部分的去除。在项目的当前阶段数据库就是无关紧要的，它只不过是一项用来存储和访问数据的技术而已； - 本次迭代的用户素材 - 增加新雇员； - 删除雇员； - 登记时间卡； - 登记销售凭条； - 登记协议服务费； - 更改雇员明细（例如，每小时报酬，会费）； - 在当日运行薪水支付系统； - 增加新雇员 - `AddEmp - EmpID、name、address、(hourly-rate | monthly-salary | commission-rate)` - 使用 AddEmp 操作可以增加新的雇员，addEmp 的三种形式中共享 EmpID、name、address 字段； - 我们可以使用 COMMAND 模式创建一个具有 3 个派生类的抽象基类 AddEmployeeTransaction，这三个派生类是 AddHourlyEmployee-Transaction、AddSalariedEmployee-Transaction 和 AddCommissionedEmployeeTransaction； - 通过把每项工作划分进中级的类中，这个结构很好地遵循了单一职责原则（SRP）； - 登记时间卡 - `TimeCard - EmpID、date、hours` - 执行 TimeCard 操作时，系统会创建一条时间卡记录，并把该记录和对应的雇员记录关联起来； - 该用例指出，一些操作指南应用于某些种类的雇员，这加强了不同种类的雇员应该用不同的类表示的观点； - 登记销售凭条 - `SalesReceipt - EmpID、date、amount` - 执行 SalesReceipt 操作时，系统会创建一条新的销售凭条记录，并把该记录和对应的应支付酬金的雇员关联起来； - 登记协议服务费 - `ServiceCharge <memberID> <amount>`； - 执行这个操作时，系统会创建一条服务费用记录，并把该记录和对应的协会成员关联起来； - 更改雇员明细 - 在薪水计算中使用 STRATEGY 模式或许更为恰当，Employee 类中可以持有一个名为 PaymentClassification 的策略类，这样坐的好处是因为可以无需改动 Employee 对象的任何部分即可更换 PaymentClassification 对象。 - 对于协会成员关系应用了 NULL OBJECT 模式。每个 Employee 对象包含一个具有两种形式的 Affiliation 对象。如果 Employee 对象包含 NoAffiliation 对象，那么他的薪水除了老板外不会被任何组织调整。然而，如果 Employee 对象包含 UnionAffiliation 对象，那么该雇员就必须要支付 UnionAffiliation 对象中记录的会费和服务费。 - 这些模式的使用使得该系统很好地符合了开放-封闭原则（OCP）。Employee 类对于支付方式、支付类别以及协会从属关系的变化是封闭的。这样，就可以在不影响 Employee 类的情况下向系统中增加新的支付方式、支付类别以及协会从属关系。 - 为了有效地使用 OCP，必须要搜寻并找出隐藏于应用背后的抽象。 ## 发现 - 数据库是实现细节，应该尽可能地推迟有关这些细节的决策。 - 增加雇员 - 使用 TEMPLATE METHOD 来增加雇员 - 删除雇员 - 使用 COMMAND 模式来删除雇员； - 支付薪水 - STRATEGY 模式 ## 小结 - 大多数情况下，测试用例都是先于产品代码编写的。 - 在多数情况下，测试都是以增量的方式创建，并与产品代码一起演化。只要图示合理，就依照图示编写产品代码。 - www.objectmentor.com/PPP 获取最终版本代码。