下面是基本实现，我们将以动作为中心讲解实现细节。
先是最核心的功能：支付（获取所有雇员列表-->计算每人的工资-->为每个人进行支付）。
接下来将按照上述时序给出各个关键步骤的实现和说明。
1）步骤1：获取所有雇员的列表。这个过程事实上有两个子步骤：获取所有的ID，而后通过ID获取Employee对象的指针。这两个方法非常直观，与Robert C·Martin的版本基本一致，不再额外说明。
2）步骤2：计算每个人的工资。这个步骤可以分解为：
①判断今天是否是当前雇员的工资支付日。
②计算当前雇员的总收入。
③计算当前雇员的应扣除支出。
对于①②，实际的处理会因为雇员类型的不同而不同，但为了有统一逻辑对支付这一行为进行处理，我们启用了多态。为了理解这两个步骤，要看一下雇员类的类层次结构和接口。
下面是雇员类的相关实现，两层结构，包含了判断支付日程的方法，非关键代码已经被删除：
接下来是3个子类。
CommissionEmployee子类：在这一子类中包含了一个销售凭条的数据库以及对这数据库进行调整的接口。这一数据库的基本形态是：map<Date，SalesReceipt*>itsReceipts；，这是非常常见的处理，这里不会重点说明。在计算这类员工的薪资时，会根据销售凭条的信息和提成比率进行计算。
HourlyEmployee子类：在这一子类中包含了打卡记录的数据库以及对其进行操作的接口。这一数据库的基本形态是：map<Date，TimeCard*>itsTimeCards；，这也是非常常见的处理，这里不进行重点说明。对于这类员工，将根据工作时间来计算工资。
这样，下面两个步骤的实现就完成了。(www.xing528.com)
①判断今天是否是当前雇员的工资支付日。
②计算当前雇员的总收入。
接下来需要关注第三个子步骤：计算当前雇员的应扣除支出。
应扣除的东西有两个：一是会费；二是参加某些活动的费用。这两点统一在UnionAffiliationDatabase中处理。在这一数据库中统一维护了每个雇员会费的值，以及每次活动的记录（ServiceCharge）。在每次活动记录中包含了雇员的ID。这部分内容与大多数据库操作一致要有增加/删除等内容，这里略过。
对应扣除金额的计算主要有两个步骤：一是累加所有的参加活动的费用；一是累加会费，最后两者的和就是应扣除金额。
这样，下面3个步骤的实现就完成了。
①判断今天是否是当前雇员的工资支付日。
②计算当前雇员的总收入。
③计算当前雇员的应扣除支出。
3）步骤3：接下来需要关注第三步。
①对当前雇员进行支付。
当前我们把支付这一行为封装到了PaymentDatabase里面，PaymentDatabase中维护了每个员工的支付信息。进行支付的时候，只要读取指定员工的支付信息，而后进行支付即可。
这样主体功能就实现了，至于各种数据库的增、删、改、查、操作，测试代码并无特别之处，为了节省篇幅，这里就略过了。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
