敏捷软件开发之薪水支付案例

项目的描述

1. 第一步：获取来自与客户交谈之后的用户素材。
   1. 有些雇员是钟点员工。
   2. 有些雇员完全以月薪进行支付。
   3. 同时，对于一些带薪雇员，会根据他们的销售情况，支付给一定数量的酬金。
   4. 雇员可以选择支付方式。
   5. 一些雇员会加入协会。
   6. 薪水支付程序每个工作日运行一次。
2. 规格说明
   

开发过程中的一点记录

1. 数据库是实现细节，应该尽可能地推迟考虑数据库。
2. 抽象的定义：本质部分的放大，无关紧要部分的去除。
3. 起先看到的UML图只不过是白板上匆忙绘制的草图。（用户素材—>用例分析）
4. 画UML图和用例图应该是程序员必掌握的技能。
5. 静态模型对应的是UML图，动态模型对应的是用例图。

遇到的问题

1. 构造函数传递过来的值会报错

   1. 报错原因为POJO对象的属性类型不应该定义为基本类型，而应该定义为包装类。
   2. 错误理解：一般基本类型可以set进包装类，但是包装类不能set进基本类型。
   3. 正确解析：避免报空指针异常，当传递参数属性值为null时，构造函数不能给基本类型属性赋值，会报空指针异常。如果定义成包装类对象，则可以避免。
   4. 常见用法：在数据库与对象(ORM)映射中最常见。

2. Set函数的使用

   1. 对于一个对象，如果是只会通过构造函数设置属性值的情况，则无需在函数中设置set函数值，当要使用时才在方法中设置set函数。
   2. 当然，对于POJO对象，我们经常采用set(),get()方法设置与获取属性值。

3. 测试代码的书写顺序问题

   1. 写测试代码也得按照业务代码的书写逻辑，为了养成良好的编程习惯。
   2. 测试代码中也得遵循先有非空校验，后才能实例的方法。
   3. 测试代码中同时应该先判断实例的类型（instanceof）,后才能向下转型。

4. 构造器问题

   1. 在子类继承父类的关系中，如果子类有重载的构造函数（没有默认函数），同时函数中没有指定引用的父类构造函数，那么会默认引用父类的默认构造函数，如果此时父类没有默认的构造函数，会编译报错。

5. 值传递与引用传递

   1. 在修改EmployName（ChangeNameTransaction）中，由于通过GpayrollDatabase.getEmployee(itsEmpid)获取的Employee是引用传递，修改对象的属性值之后就无需GpayrollDatabase.addEmployee（）了。

6. 抽象类与接口的使用

   1. 如果一个对象，并不会实例化，并且其目的不是为实现代码的复用，那么就应该定义为接口，而不是实体类。像案例中的Affiliation，PaymentClassification，PaymentMethod，PaymentSchedule
   2. 因为它们都表示某种抽象出来的行为。

7. +=与+的优先级别

   1. 在java中，+的运算是从右到左，=的运算也是从右到左，很容易理解，+=的运算即使没有带括号也是先算+,再赋值。

8. 在testcase中按照包名测试

   1. 会不会存在测试顺序的问题?

9. 接口封装的灵活使用

   1. 程序把本来PaymentClassifition需要的时间段值通过PayCheck封装，转移到Schedule了，这个叫移花接木啊，轻功水上漂，厉害厉害！

10. 问题的最后还是用到了DateUtils,哈哈哈，喜悦之情溢于言表。

    1. 把方法往上抽取，到接口，把接口变成抽象类，再发现别的继承体系的类也需要这个方法，于是将isInPayPeriod()方法放置到公共类。

• github代码分支地址