正文：

在Java的世界里，我们常常面临这样的困境：一个核心方法需要支持多种调用场景，但参数组合却像俄罗斯套娃般层层叠加。传统的全参数构造方法很快会变成这样：

java processOrder(String userId, String productId, Integer quantity, String couponCode, String deliveryType, String paymentMethod, String invoiceTitle) { // 业务逻辑... }

当调用者只需要部分参数时，不得不填满一堆null值，既丑陋又容易出错。更可怕的是，每新增一个可选参数，方法签名就要被迫修改。面对这种参数爆炸的困局，我们该如何破局？

方案一：传统重载技法（适用简单场景）

java
public class PaymentService {
// 基础方法
public void pay(BigDecimal amount) {
pay(amount, "DEFAULT_CURRENCY");
}

// 带货币类型
public void pay(BigDecimal amount, String currency) {
    pay(amount, currency, "ALIPAY");
}

// 完整参数
public void pay(BigDecimal amount, String currency, String channel) {
    // 实际支付逻辑
}

}

优势：
1. 编译时类型安全，IDE自动提示清晰
2. 无需额外类型定义，上手成本低

致命缺陷：
当可选参数超过3个时，方法数量会呈指数级增长。若存在5个可选参数，理论上需要2^5=32个重载方法！这在真实业务系统中根本不可行。

方案二：建造者模式（复杂场景首选）

java
public class OrderBuilder {
private String userId;
private String productId;
private int quantity = 1; // 默认值
private String couponCode;

// 链式设置器
public OrderBuilder userId(String userId) {
    this.userId = userId;
    return this;
}

public OrderBuilder quantity(int quantity) {
    this.quantity = quantity;
    return this;
}

// 终结方法
public Order build() {
    return new Order(this);
}

}

// 使用示例
new OrderBuilder()
.userId("U123")
.productId("P456")
.build();

实战技巧：
1. 对必填参数在build()方法中做校验，抛出IllegalArgumentException
2. 通过final类+私有构造器强制使用Builder
3. IntelliJ IDEA可使用@Builder注解自动生成（Lombok）

深度优势：
- 参数组合自由灵活，新增参数无需修改调用方
- 链式调用形成DSL（领域特定语言），代码即文档
- 与Spring配置风格天然契合，降低认知成本

方案三：参数对象模式（领域驱动设计推荐）

java
public class SearchCriteria {
private String keyword;
private Date startDate;
private Date endDate;
private SortOrder sortOrder = SortOrder.DESC; // 默认值

// 静态工厂方法
public static SearchCriteria byKeyword(String keyword) {
    return new SearchCriteria().setKeyword(keyword);
}

// 流畅设置器
public SearchCriteria dateRange(Date start, Date end) {
    this.startDate = start;
    this.endDate = end;
    return this;
}

}

// 服务层使用
public List searchProducts(SearchCriteria criteria) {
// 使用criteria构造查询
}

业务价值：
1. 将参数集群封装为领域对象，提升业务语义表达
2. 参数校验逻辑内聚，避免业务方法充斥验证代码
3. 与DTO转换无缝结合，适合分层架构

决策矩阵：如何选择最佳方案？

| 场景特征 | 推荐方案 | 典型案例 |
|-----------------------|----------------------|----------------------------|
| 参数≤3且无扩展预期 | 方法重载 | 工具类静态方法 |
| 参数≥4或未来可能扩展 | Builder模式 | 订单创建/支付流程 |
| 参数集群代表业务概念 | 参数对象 | 查询条件/报表参数 |

避坑指南：参数设计的黄金法则

1. 默认值陷阱
   使用包装类型（如Integer而非int）才能实现真正的可选：
   java public void configure(int timeout = 30) // 错误！仍然是必填 public void configure(Integer timeout) // 正确

2. 空指针防御
   对可选参数进行null安全处理：
   java public void updateProfile(UserProfile profile) { String email = Optional.ofNullable(profile.getEmail()) .orElse("default@domain.com"); }

3. 参数约束
   使用JSR 303注解实现声明式校验：java
   public class RegistrationParam {
   @NotBlank
   private String username;

   @Email
   private String email; // 可选
   }

扩展思考：当遇到动态参数

对于完全无法预测的参数扩展（如配置项），可以采用Map收容：
java public void applySettings(Map<String, Object> config) { // 类型安全转换 Integer timeout = (Integer)config.getOrDefault("timeout", 30); }
但务必在文档中明确Key的契约，避免成为"黑洞接口"。