第42章代码坏味道

课程目录第42章代码坏味道

第42章：代码坏味道：过长参数列表 - 实战引入参数对象

说实话，我见过最夸张的一个方法，参数列表足足有17个参数。那是在一个老旧的订单处理系统里，调用方传参传得晕头转向，经常传错顺序。更可怕的是，新增一个参数就得改所有调用点——这简直就是一场灾难。

过长参数列表，是代码里非常常见的坏味道。它不像死循环那样直接让程序崩溃，但它会慢慢侵蚀代码的可维护性。我个人习惯是：一旦参数超过3个，就要开始警惕了。

为什么参数列表会变长？

你想想看，一个方法最初可能只需要两个参数。随着需求迭代，今天加一个筛选条件，明天加一个配置项，后天再加一个标志位……慢慢地，参数就堆起来了。

我在项目中遇到过最典型的情况：一个查询方法，参数从3个膨胀到9个。原因很简单——每次新需求来，大家都觉得“加个参数最省事”。没人愿意重构，也没人敢动已有的调用方。

但这样做的代价是什么？

调用方痛苦：每次调用都要传一堆参数，还得记住顺序
测试困难：组合爆炸，测试用例写不完
扩展性差：加一个参数就得改所有调用点
可读性差：看到一长串参数，根本不知道哪些是必须的

引入参数对象：最直接的解法

解决过长参数列表，最常用的手法就是引入参数对象。说白了，就是把一组逻辑上相关的参数，封装成一个对象。

举个例子，假设我们有一个搜索订单的方法：

// 重构前：7个参数，调用方快疯了
public List<Order> searchOrders(
    String orderId,
    String customerName,
    Date startDate,
    Date endDate,
    String status,
    BigDecimal minAmount,
    BigDecimal maxAmount
) {
    // 查询逻辑...
}

调用的时候长这样：

searchOrders("ORD001", null, null, null, "PAID", null, null);

嗯，这里要注意：传一堆null，代码既难看又容易出错。万一传错顺序，bug就悄悄埋下了。

重构后，我们引入一个参数对象：

// 参数对象
public class OrderSearchCriteria {
    private String orderId;
    private String customerName;
    private DateRange dateRange;  // 日期范围也可以封装
    private String status;
    private AmountRange amountRange;  // 金额范围也可以封装
    
    // 用建造者模式或静态工厂方法创建
    public static OrderSearchCriteriaBuilder builder() {
        return new OrderSearchCriteriaBuilder();
    }
}

// 重构后的方法
public List<Order> searchOrders(OrderSearchCriteria criteria) {
    // 查询逻辑...
}

调用方变得清爽多了：

OrderSearchCriteria criteria = OrderSearchCriteria.builder()
    .orderId("ORD001")
    .status("PAID")
    .build();

searchOrders(criteria);

核心要点：参数对象不是简单地把参数塞进一个类里。它应该是有业务含义的、内聚的一组数据。比如上面的 OrderSearchCriteria，它代表的就是“订单搜索条件”这个业务概念。

什么时候该引入参数对象？

我总结了几条判断标准：

判断标准	说明
参数超过3个	3个是警戒线，超过就要考虑
参数经常一起出现	比如 startDate 和 endDate 总是成对出现
参数有默认值	很多参数是可选的，用参数对象可以优雅处理
参数之间有约束关系	比如 startDate 必须小于 endDate，可以在对象内部校验
多个方法共享同一组参数	说明这组参数是一个业务概念

我的小技巧：当你发现自己在写注释说明参数含义时，比如 // 开始日期、// 结束日期，这就是一个信号——该引入参数对象了。

实战案例：报表生成器

我记得有一次重构一个报表生成模块。原来的方法长这样：

public Report generateReport(
    String reportType,
    Date startDate,
    Date endDate,
    String groupBy,
    boolean includeDetails,
    boolean includeSummary,
    String sortBy,
    String format,
    String locale
) {
    // 9个参数...
}

调用方每次都要传9个参数，而且很多参数有默认值。更糟糕的是，新增一个“是否包含图表”的参数，又得改所有调用点。

重构后，我们引入了 ReportConfig 参数对象：

public class ReportConfig {
    private String reportType;
    private DateRange dateRange;
    private String groupBy;
    private boolean includeDetails;
    private boolean includeSummary;
    private String sortBy;
    private String format;
    private String locale;
    
    // 使用建造者模式
    private ReportConfig(Builder builder) {
        this.reportType = builder.reportType;
        this.dateRange = builder.dateRange;
        this.groupBy = builder.groupBy;
        this.includeDetails = builder.includeDetails;
        this.includeSummary = builder.includeSummary;
        this.sortBy = builder.sortBy;
        this.format = builder.format;
        this.locale = builder.locale;
    }
    
    public static class Builder {
        // 必填参数
        private String reportType;
        private DateRange dateRange;
        
        // 可选参数，设置默认值
        private String groupBy = "day";
        private boolean includeDetails = true;
        private boolean includeSummary = true;
        private String sortBy = "date";
        private String format = "PDF";
        private String locale = "zh_CN";
        
        public Builder(String reportType, DateRange dateRange) {
            this.reportType = reportType;
            this.dateRange = dateRange;
        }
        
        public Builder groupBy(String groupBy) {
            this.groupBy = groupBy;
            return this;
        }
        
        // 其他setter方法...
        
        public ReportConfig build() {
            // 可以在build时做校验
            if (reportType == null || dateRange == null) {
                throw new IllegalArgumentException("reportType和dateRange不能为空");
            }
            return new ReportConfig(this);
        }
    }
}

调用方只需要关注自己需要的参数：

ReportConfig config = new ReportConfig.Builder(
    "SALES", 
    DateRange.lastMonth()
)
.includeDetails(false)
.format("EXCEL")
.build();

Report report = reportService.generateReport(config);

避坑指南：我曾经见过有人把参数对象搞成一个巨大的“上帝对象”，里面塞了几十个字段。这其实是从一个极端走向另一个极端。参数对象应该内聚，只包含逻辑上相关的参数。如果参数太多，考虑拆分成多个参数对象。

参数对象的进阶用法

引入参数对象不只是为了减少参数个数。它还能带来额外的好处：

参数校验集中化：在参数对象的构造方法或build方法里做校验，避免每个方法都重复校验
默认值管理：在参数对象里设置默认值，调用方不用每次都传
业务逻辑内聚：比如 DateRange 可以包含 lastMonth()、thisWeek() 等静态工厂方法
易于扩展：新增参数只需要在参数对象里加字段，不影响已有调用方

来看一个更复杂的例子。假设我们有一个数据导出功能：

// 重构前：参数越来越多
public void exportData(
    String tableName,
    String[] columns,
    String whereClause,
    String orderBy,
    int pageSize,
    int pageNumber,
    String outputFormat,
    String outputPath,
    boolean includeHeader,
    String delimiter,
    String encoding
) {
    // 11个参数...
}

重构后，我们可以拆分成多个参数对象：

public class ExportConfig {
    private DataSourceConfig dataSource;  // 数据源配置
    private QueryConfig query;            // 查询配置
    private OutputConfig output;          // 输出配置
    private FormatConfig format;          // 格式配置
}

public class QueryConfig {
    private String tableName;
    private String[] columns;
    private String whereClause;
    private String orderBy;
    private Pagination pagination;
}

public class OutputConfig {
    private String outputFormat;
    private String outputPath;
    private boolean includeHeader;
    private String delimiter;
    private String encoding;
}

这样拆分后，每个参数对象都职责清晰，而且可以独立测试和复用。

引入参数对象的步骤

如果你现在就想重构，可以按这个步骤来：

识别参数组：找出经常一起出现、逻辑相关的参数
创建参数类：给这个类起一个有业务含义的名字
添加字段和构造方法：把参数变成类的字段
迁移调用方：逐个修改调用方，使用新的参数对象
删除旧方法：所有调用方都迁移后，删除旧的重载方法

我的建议：不要一次性改所有调用方。可以先保留旧方法，用重载的方式过渡。等所有调用方都迁移完，再删除旧方法。这样风险最小。

知识体系图

下面这张图展示了过长参数列表的识别、重构手法和收益：

总结

引入参数对象，是解决过长参数列表最直接、最有效的手法。它不只是把参数塞进一个类里，更重要的是让代码的意图更清晰，让调用方更轻松。

我个人习惯在代码审查时特别关注方法的参数个数。一旦发现超过3个，就会问一句：“这里是不是该引入参数对象了？”

记住：好的代码，方法签名应该像一句简洁的话，而不是一篇冗长的文章。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录