带必填字段的参数化构造器搭配setter能否替代Builder设计模式？

1. 为何不能采用包含必填字段的参数化构造器搭配setters设置可选字段的方案，替代Builder Pattern？ #

这个方案存在几个比较明显的缺陷：

• 会产生半初始化的中间态对象：调用构造器创建对象之后、所有setter执行完成之前，这个对象是不完整的，如果此时被其他业务逻辑拿到使用，大概率会触发业务错误，且这类问题排查成本极高。
• 构造器参数易传错：如果必填字段数量较多、且存在多个同类型参数时，参数顺序很容易写反，编译器不会抛出异常，直到业务运行出错才能发现问题。
• 校验逻辑零散：如果字段之间存在依赖规则（比如设置了会员过期时间就必须绑定对应会员等级），这种方案没法做统一的前置校验，只能把规则散落在各个业务逻辑里，维护成本很高。

2. 相比参数化构造器加setter的方案，Builder Design Pattern具备哪些优势？ #

除了支持不可变对象构造之外，还有这些核心优势：

• 可读性与可维护性更强：每个参数设置都对应明确的方法名，无需记忆构造器参数顺序，也从根源上避免了同类型参数传反的问题，代码读起来一目了然。
• 参数校验更集中：可以在build()方法中统一做全量参数校验，包括必填项是否遗漏、关联字段的规则是否符合要求，只有校验通过才会返回最终对象，完全不会产生无效的中间态对象。
• 构造逻辑可复用：如果需要生成多个配置相似的对象，可以提前给Builder设置好公共参数，再基于同一个Builder实例调整差异字段即可，不用每次创建对象都重复写一堆相同的setter代码。
• 线程安全性更高：Builder本身是可变的，但最终对象只会在build()执行完成后才对外暴露，不会出现半初始化的对象被多线程同时访问的问题。

3. 若业务场景不需要Immutability，使用参数化构造器搭配setters替代Builder Pattern是否合理？ #

这个没有绝对的对错，需要结合实际场景判断：
如果符合以下所有条件，用参数化构造器+setter完全合理：

• 类的字段总量很少，必填字段不超过3个，也不存在同类型的必填参数，不会出现参数传反的问题
• 字段之间没有强依赖规则，哪怕可选字段没有赋值，对象被直接使用也不会产生业务异常
• 没有批量构造相似配置对象的需求，不需要复用构造逻辑
  但如果存在以下任意一种情况，哪怕不需要不可变特性，也更推荐用Builder模式：
• 字段数量超过5个，或者存在多个同类型的参数，容易出现构造器参数传错的问题
• 字段之间有依赖校验规则，需要统一做参数合法性判断
• 需要频繁构造大量配置相似的对象，有复用构造逻辑的需求

内容的提问来源于stack exchange，提问作者Vishal