Question

我知道这不是好设计，如果有选择，我宁愿使用setter / getter。但我正在编写一个JPA实体，需要这个构造函数用于JPQL目的，所以总之我必须使用构造函数来启动字段和嵌入实体的值。

所以我必须在实体的构造函数中创建40个参数，并且必须让JPA经常使用构造函数。我一直在线搜索，并没有发现任何说明java构造函数中的超大参数列表可能会导致性能问题，但可能是我没有做足够的功课。

所以任何建议都表示赞赏，表现是唯一的问题。感谢

Answer 1

性能是唯一关注的问题

超大参数列表的问题实际上与性能无关 - 您的性能可能与使用setter方法设置对象时的性能一样好或更好。当然，与所有与性能相关的案例一样，最好的建议是尝试并对其进行基准测试，看看是否可以衡量任何差异。如果您的代码中没有任何一部分已被识别为放慢速度，那么根本不应该成为您的关注点，更不用说您的 >仅关注。

但是，任何具有如此大的参数列表的方法或构造函数都会使代码无法维护且容易出错，而且您应该纯粹为了代码可维护性而寻求其他选项。

Answer 2

要简化构造对象，您应该使用Builder模式：

public class SomeComplexClass

    public static class SomeComplexClassBuilder {

        /* fields to set for the constructor */

        /* getters and setters for those fields*/

        public SomeComplexClass build() {
            //verify the fields are all correct for the object
            return new SomeComplexClass(/* pass the necessary fields*/);
        }

    }

    private SomeComplexClass(/*arguments*/) {...}

}

然后你可以使用构建器构建：

SomeComplexClass obj = new SomeComplexClass.SomeComplexClassBuilder()
                                           .setSomething(/*argument*/)
                                           .setAnother(/*argument*/)
                                           .build();

您可以链接方法以返回构建器对象以执行所有操作：

public SomeComplexClassBuilder setField(Object argument) {
    this.argument = argument;
    return this;
}

Answer 3

如果构造函数中的参数太多，是否存在任何性能问题？ 在这方面没有什么可担心的，对此没有任何性能问题。

这是因为查询执行本身（一旦到达数据库）的开销加上将查询发送到网络并接收数据所涉及的网络开销比过多参数引入的任何惩罚高几个数量级。在构造函数中。

尝试寻找替代方案的原因是代码可维护性。您可能存在具有许多列的高度非规范化表。这意味着数据库行通常可以拆分为多个嵌入式。下面的示例显示了如何将4个相关列分组到可嵌入的Address类中：

@Entity
@Table("MANY_COLS_TABLE")
public class User {
   private Long id;
   @Embedded
   private Address address;
}

@Embeddable
public class Address {
    private String streetAdress;
    private int number;
    private String city;
    private ZipCode zipcode;
}

如果构造函数中的参数太多，是否存在任何性能问题？

3 个答案: