方法参数过多应封装为有业务语义的record或dto、按职责拆分方法、用builder处理可选参数，禁用map/jsonobject传参。
方法参数过多是典型的代码坏味道，它直接削弱可读性、增加调用出错概率，并阻碍后续扩展。核心思路不是“少传参数”，而是让参数更有结构、更贴近业务语义。
把零散参数封装成有意义的对象
当一个方法接收超过3个基础类型参数（如 String、int、boolean 等），尤其是它们逻辑相关时，说明这些数据本应属于同一个概念。比如创建用户时传 name、email、age、isActive、createdAt，就该合并为一个明确的载体。
- 定义 record 或普通类：record CreateUserRequest(String name, String email, int age, boolean active) {}
- 方法签名从 public User create(String n, String e, int a, boolean act) 改为 public User create(CreateUserRequest req)
- 调用方不再依赖参数顺序，IDE 能自动提示字段，重命名字段时编译器立即报错，而非运行时报 ClassCastException
按职责拆分方法，减少单次调用所需信息
参数多往往是因为方法承担了太多事。比如 processOrder(Order order, String paymentMethod, boolean sendEmail, boolean updateStock, String warehouseId, boolean logAudit) —— 这已不是“处理订单”，而是“调度整个订单生命周期”。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 提取独立行为：processPayment(order, paymentMethod)、sendConfirmationEmail(order)、reserveInventory(order, warehouseId)
- 主流程变为组合调用，每个子方法只需自己关心的那部分数据
- 后续新增需求（如加风控校验）只需新增方法，不改动原有参数列表
用 Builder 模式支持可选参数与清晰构建过程
当部分参数可选、且组合方式多样时，直接传对象仍可能产生大量 null 或默认值判断。Builder 能让调用端显式表达意图。
- 新建 User.builder().name("Alice").email("a@b.com").active(true).build()
- Builder 内部做必填校验，避免空指针；链式调用提升可读性
- 比 new User(null, "a@b.com", 0, true, null, ...) 更安全、更自解释
警惕 Map 和 JSONObject 当参数
用万能 Map 或 JSON 代替具体类型，看似灵活，实则放弃编译期检查和语义表达，后续必然伴随大量强转和 get("xxx")，是坏味道的温床。
- 将入参统一建模为 record 或 DTO，例如 OrderSubmitRequest(List
items, Address shippingAddr, Coupon coupon) - Spring MVC、Jackson 等框架天然支持 JSON ↔ 对象双向绑定，无需手动解析
- 字段变更时 IDE 可全局重构，而 Map 的键名写错只能等到运行时报错
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
