在java构造函数中，应先验证传入参数的有效性，再将参数赋值给实例变量；若前置条件检查使用未初始化的`this.field`，会导致空指针或逻辑错误，正确做法是直接校验形参。
在设计不可变或强约束的类时，构造函数承担着关键的状态合法性保障职责。一个常见误区是：在构造函数中将实例变量初始化（如 this.healthProvider = healthProvider）和前置条件检查（如 if (this.healthProvider == null)）的顺序混淆，从而引发逻辑错误或测试失败。
❌ 错误写法：用未赋值的 this.field 做校验
public Provider(String healthProvider) {
if (this.healthProvider == null) { // ❌ this.healthProvider 尚未初始化！始终为 null
throw new IllegalArgumentException(PROVIDER_NULL);
}
if (this.healthProvider.isBlank()) { // ❌ 同样，调用 null.isBlank() → NullPointerException
throw new IllegalArgumentException(PROVIDER_ISBLANK);
}
this.healthProvider = healthProvider; // ✅ 赋值在此之后 —— 已晚
this.patients = new ArrayList<>();
}该写法在首次访问 this.healthProvider 时，其值仍为默认 null（实例变量未显式初始化前），因此第一个判空看似“通过”，实则校验的是无意义的默认值；而 .isBlank() 更会直接触发 NullPointerException，导致构造失败且掩盖真实问题。
✅ 正确写法：校验形参，再赋值，最后初始化其他字段
public Provider(String healthProvider) {
// ✅ 直接校验传入参数 —— 安全、清晰、符合语义
if (healthProvider == null) {
throw new IllegalArgumentException(PROVIDER_NULL);
}
if (healthProvider.isBlank()) {
throw new IllegalArgumentException(PROVIDER_ISBLANK);
}
// ✅ 参数合法后，再赋值给实例变量
this.healthProvider = healthProvider;
// ✅ 其他依赖于对象状态的初始化（如集合）可在此后进行
this.patients = new ArrayList<>();
}⚠️ 关键原则与注意事项
- 校验对象是“输入”，不是“当前状态”：前置条件（precondition）的本质是确保构造函数接收的参数满足业务契约，而非检查尚未建立的对象内部状态。
- 避免副作用前置：过早初始化 this.patients 等字段虽不会导致空指针，但若校验失败抛出异常，这些已分配的对象将被丢弃，造成轻微资源浪费（对 ArrayList 可忽略，但对IO/连接类资源需谨慎）。
- 提升可读性与可维护性：将校验集中于开头，形成统一入口守卫（guard clause），符合防御性编程习惯，也便于后续添加日志、断言或统一校验工具（如 Objects.requireNonNull、Apache Commons Validate.notBlank）。
- JUnit 测试行为差异的根源：你观察到的测试通过/失败差异，正是由于第一种写法在 isBlank() 处抛出 NullPointerException（非预期的 IllegalArgumentException），导致断言失败；而第二种虽能通过，但逻辑本末倒置——它把校验放在赋值之后，虽“侥幸”避免了NPE，却丧失了参数校验的纯粹性，且若字段有复杂初始化逻辑（如 new ExpensiveResource(healthProvider)），可能引发更隐蔽的问题。
总结
构造函数的推荐结构为：参数校验 → 字段赋值 → 辅助状态初始化。永远校验形参（healthProvider），而非 this.healthProvider；这不仅是技术正确性要求，更是清晰表达设计意图、保障类不变量（class invariant）的第一道防线。
