当多个方法频繁接收语义相关、成组出现的参数时，应封装为参数对象以提升可读性与可维护性；适用信号包括：3+关联参数、多处重复传递、调用方拼装复杂、校验逻辑分散；设计上需命名具体、升级为带行为的小对象、构造函数轻量验证、优先不可变；重构分三步：新增重载方法、逐步迁移调用方、下线旧接口；避免将横切关注点纳入参数对象。
当多个方法频繁接收一串语义相关、成组出现的参数时，把它们封装成一个独立对象，能显著提升代码可读性与可维护性。这不是为了“炫技”，而是解决真实痛点：参数列表越来越长、调用时容易传错顺序、新增字段要改所有调用点、无法复用校验逻辑。
什么情况该考虑引入参数对象
留心这些信号：
- 方法签名里连续出现 3 个及以上语义关联的参数，比如
createOrder(String customerId, String productId, int quantity, String currency, BigDecimal price) - 同一组参数在多个方法间重复传递（如创建、更新、校验订单都用这五个字段）
- 调用方常需临时拼装参数，例如先查用户再查商品再组合传参，中间变量多且易出错
- 部分参数有业务约束（如 quantity > 0、currency 必须是 ISO 4217 码），但校验逻辑散落在各处
怎么设计这个参数对象
它不是简单的数据容器，而应体现领域语义：
- 命名要具体，比如叫
OrderRequest而不是ParamDto；若用于下单场景，也可叫PlaceOrderCommand - 把原始类型字段升级为带行为的小对象：用
Money替代BigDecimal + String currency，用ProductId包装字符串 ID 并内置格式校验 - 构造函数做轻量级验证（如非空、范围检查），避免无效对象流出；不建议在构造里做远程调用或复杂计算
- 提供不可变（immutable）设计更安全，尤其在并发或作为 Map key 时；若需修改，用 with 方法或 Builder 模式
重构步骤与注意事项
分三步平稳过渡，不破坏现有功能：
- 先新建参数类，保留原有方法不变，仅作为“备用选项”——加一个重载方法，接受新对象，内部转成老参数调用原逻辑
- 逐步把调用方迁移到新接口，IDE 的“查找引用”和“安全重命名”能帮你快速定位所有调用点
- 确认无遗漏后，删除旧方法，或标记
@Deprecated并设好下线时间 - 注意别让参数对象变成“上帝对象”：只收真正强相关的字段；像日志 traceId、用户权限这类横切关注点，仍应通过上下文或单独参数传递
一个精简示例（Java）
重构前：
void processPayment(String orderId, String userId, String cardNo, String expiry, String cvv, BigDecimal amount, String currency) { ... }重构后：
void processPayment(PaymentRequest request) { ... }其中 PaymentRequest 内部已封装卡号脱敏、有效期解析、金额货币一致性校验等逻辑，调用方只需一行：processPayment(new PaymentRequest(orderId, user, card))，清晰、安全、不易错。
