在Java里做薪资计算，构造函数参数怎么设计，会直接影响类的复用性和计算逻辑的稳定性。周薪含加班费这一需求虽然公式简单，但实现时常见两种错误：一是把实际工作时长也当作构造参数，导致每算一次工资都要新建对象；二是把加班判断和费用计算写在UI或工具类里，造成规则重复。正确做法是让构造函数只接收相对固定的薪酬配置，把实际工时交给计算方法。
一、构造函数参数应该包含哪些数据
员工周薪计算通常涉及几个基础数据：姓名或编号、时薪、标准工时、加班费率倍数。这些数据在员工入职或合同期内基本不变，适合通过构造函数注入。构造函数可以让对象在创建时就具备完整状态，后续计算方法只依赖这些字段，无需反复传参。
为什么不建议把实际工作时长也放进构造函数？因为实际工时是每次计算时都会变化的量。如果把 hoursWorked 作为构造参数，那么每算一次工资都要 new 一个对象，对象生命周期和业务周期就会耦合在一起。更严重的是，一个员工对象可能被多处复用，如果某个调用方修改了工时字段，其他调用方的结果也会受到污染。
下面是一个合理的 Employee 类设计，构造函数只接收固定薪酬配置，并且字段全部声明为 private final，确保对象创建后不可变。
public class Employee {
private final String name;
private final double hourlyRate;
private final double standardHours;
private final double overtimeRateMultiplier;
public Employee(String name, double hourlyRate, double standardHours, double overtimeRateMultiplier) {
if (name == null || name.trim().isEmpty()) {
throw new IllegalArgumentException("姓名不能为空");
}
if (hourlyRate <= 0) {
throw new IllegalArgumentException("时薪必须大于0");
}
if (standardHours < 0 || standardHours > 168) {
throw new IllegalArgumentException("标准工时必须在0到168之间");
}
if (overtimeRateMultiplier < 1.0) {
throw new IllegalArgumentException("加班费率倍数不能小于1");
}
this.name = name;
this.hourlyRate = hourlyRate;
this.standardHours = standardHours;
this.overtimeRateMultiplier = overtimeRateMultiplier;
}
public String getName() {
return name;
}
public double getHourlyRate() {
return hourlyRate;
}
public double getStandardHours() {
return standardHours;
}
public double getOvertimeRateMultiplier() {
return overtimeRateMultiplier;
}
}
这里把 standardHours 设计为构造参数而不是写死成40小时，是因为不同国家、地区或合同类型的标准工时可能不同。把规则交给调用方配置，类本身只负责根据配置计算，扩展性会更好。
二、加班费计算规则与核心方法
加班费的计算通常采用分段方式：先算出常规工时和加班工时，再分别乘以对应费率。常规工时取实际工时和标准工时的较小值，加班工时取实际工时减去标准工时，如果结果为负数则归零。总周薪等于常规工时乘时薪，再加上加班工时乘时薪乘加班倍率。
把这段逻辑封装在 calculateWeeklyPay 方法中，由方法接收实际工时。这样同一个员工对象可以反复计算不同周次的工资，不需要反复创建实例。
public double calculateWeeklyPay(double hoursWorked) {
if (hoursWorked < 0) {
throw new IllegalArgumentException("工作时长不能为负");
}
double regularHours = Math.min(hoursWorked, standardHours);
double overtimeHours = Math.max(0, hoursWorked - standardHours);
double regularPay = regularHours * hourlyRate;
double overtimePay = overtimeHours * hourlyRate * overtimeRateMultiplier;
return regularPay + overtimePay;
}
上面的实现中，Math.min 负责截取不超过标准工时的部分，Math.max 负责避免加班工时出现负数。比如标准工时为40小时，实际工作45小时，则常规工时为40小时，加班工时为5小时。若实际工作38小时，则加班工时为0小时。
如果涉及金额的精确计算，double 的二进制浮点误差可能会造成小数点后精度问题。生产环境一般建议使用 BigDecimal，并在最后统一四舍五入到两位小数。下面是一个改进版本。
import java.math.BigDecimal;
import java.math.RoundingMode;
public BigDecimal calculateWeeklyPayExact(double hoursWorked) {
if (hoursWorked < 0) {
throw new IllegalArgumentException("工作时长不能为负");
}
BigDecimal rate = BigDecimal.valueOf(hourlyRate);
BigDecimal regularHours = BigDecimal.valueOf(Math.min(hoursWorked, standardHours));
BigDecimal overtimeHours = BigDecimal.valueOf(Math.max(0, hoursWorked - standardHours));
BigDecimal regularPay = rate.multiply(regularHours);
BigDecimal overtimePay = rate.multiply(overtimeHours)
.multiply(BigDecimal.valueOf(overtimeRateMultiplier));
return regularPay.add(overtimePay).setScale(2, RoundingMode.HALF_UP);
}
使用 BigDecimal.valueOf 而不是 new BigDecimal(double)，是为了避免把 double 的误差直接带入十进制计算。setScale(2, RoundingMode.HALF_UP) 表示保留两位小数，采用四舍五入。是否使用 BigDecimal 取决于业务对金额精度的要求，学习阶段用 double 理解逻辑也完全可以。
三、参数校验与不可变设计
构造函数参数一旦不合理，后续所有计算都会失去意义。例如时薪为负数、标准工时超过一周总时长，或者加班倍率低于1.0，都会让薪资结果变得荒谬。把校验放在构造函数中，可以让对象在创建阶段就拒绝非法状态，而不是等到计算时才发现问题。
校验规则应当结合业务常识：姓名不能为空；时薪必须大于0；标准工时不能为负，也不能超过一周168小时；加班费率倍数至少为1.0，否则所谓加班费反而比正常工资还低。上面的代码已经体现了这些约束。
字段设置为 private final 并且不提供 setter 方法，是实践中非常推荐的做法。不可变对象天然线程安全，可以在多个线程中共享同一个 Employee 实例，不用担心某个线程修改时薪影响另一个线程的计算。这也是 Effective Java 中一直强调的不可变对象优先原则。
如果业务后续需要调整时薪或加班倍率，不要在原对象上修改，而是创建一个新的 Employee 对象。这样历史计算结果不会受到影响，也便于审计和追踪。
四、测试用例与常见误区
为了验证计算逻辑，可以写一个简单的测试入口。下面以时薪80元、标准工时40小时、加班倍率1.5为例，分别测试38小时、40小时和45小时的周薪。
public class PayrollExample {
public static void main(String[] args) {
Employee emp = new Employee("李雷", 80.0, 40.0, 1.5);
System.out.println("工作38小时周薪：" + emp.calculateWeeklyPay(38));
System.out.println("工作40小时周薪：" + emp.calculateWeeklyPay(40));
System.out.println("工作45小时周薪：" + emp.calculateWeeklyPay(45));
}
}
输出结果分别是3040元、3200元和3800元。45小时时，常规工时40小时产生3200元，加班工时5小时按80乘1.5计算为600元，总计3800元。这个结果可以手动验算，避免测试用例本身出错。
实践中有几个常见误区需要留意：一是把实际工时放在构造函数中，导致对象无法复用；二是把加班判断逻辑写在调用方，出现多个不同版本的加班规则；三是直接用 double 做金额相等比较，容易因为精度误差得出错误结论；四是忽略标准工时的可配置性，把40小时写死在计算逻辑中。避开这些误区，构造函数参数设计就会清晰很多。
更复杂的业务场景中，加班倍率可能根据工作日、周末或法定节假日有所不同。这时可以把加班费率抽象成策略接口，但核心原则不变：构造函数只保存相对固定的配置，实际工时始终作为方法参数传入。这样类职责明确，测试和维护成本也会明显降低。