Builder模式对比参数对象：为何不直接使用参数对象传参？

你说的这种参数对象写法确实在很多场景下足够简单好用，但Builder模式能解决一些它搞不定的问题，具体来说有这几个关键点你可能没考虑到：

• 强制必填参数校验：参数对象没法从设计层面强制调用者传入必填字段——比如如果name是必须项，用参数对象的话调用者传{}也能成功实例化，你只能在构造函数里加一堆判断抛错；但Builder模式可以通过流程限制，比如必须先调用setName()才能调用build()，从根源上避免缺失必填项的情况。

• 复杂对象的分步构建：如果对象创建需要依赖异步操作，或者要分步骤根据不同条件组装不同部分，参数对象就显得很笨拙。比如先同步获取用户基本信息，再异步拉取地址数据，最后生成对象——Builder可以一步步调用方法设置属性，等所有数据准备齐全后再执行build()；而参数对象必须等所有数据都就绪才能传入构造函数。

• 不可变对象的高效创建：如果想创建实例后就禁止修改内部状态（不可变对象），参数对象的构造函数赋值没问题，但后续要调整配置生成新对象时，得重新组装一个完整的参数对象再实例化。而Builder模式可以在build()时返回冻结的对象，同时保留Builder实例继续修改配置，快速生成新实例：

  const userBuilder = new UserBuilder().setName('Alice').setAge(30);
  const user1 = userBuilder.build(); // 实例不可修改
  const user2 = userBuilder.setEmail('alice@example.com').build(); // 基于已有配置生成新对象
  

• 更强的可读性与语义化：当参数数量多、可选配置复杂时，Builder的链式调用可读性远高于参数对象。比如new UserBuilder().setName('Bob').setAge(25).setAddress('北京').build()，一眼就能看清每个配置项的作用；而参数对象如果有大量可选字段，调用时可能会写成{name: 'Bob', age:25, address:'北京', /* 一堆注释说明其他可选字段 */}，语义清晰度差很多，尤其是参数有默认值或依赖关系时。

• 封装复杂创建逻辑：如果对象创建需要复杂计算或条件判断，比如根据年龄自动设置isAdult字段，Builder可以把这些逻辑封装在自身方法里（比如setAge(age)内部判断并赋值isAdult）；而参数对象只能把逻辑暴露在调用方或臃肿的构造函数里，破坏封装性。

当然，如果你只是创建简单、参数少的对象，参数对象完全够用，没必要过度设计用Builder。但当对象结构复杂、需要必填校验、分步构建，或者追求更高的可读性和封装性时，Builder模式的优势就体现出来了。

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