具有所有类属性的构造函数还是具有设置器的默认构造函数？答案

【问题标题】：Constructor with all class properties or default constructor with setters?具有所有类属性的构造函数还是具有设置器的默认构造函数？
【发布时间】：2010-10-24 06:12:39
【问题描述】：

以下是两种方法：

具有所有类属性的构造函数

优点：我必须输入准确数量的参数类型，所以如果我出错，编译器会警告我（顺便说一句，有没有办法防止错误地切换参数列表上的两个整数的问题？ )

缺点：如果我有很多属性，实例化行可能会变得很长，并且可能跨越两行或更多行

setter 和默认的空构造函数

优点：我可以清楚地看到我在设置什么，所以如果我做错了什么，我可以在输入时立即查明它（我不能犯之前切换两个变量的错误同类型）

缺点：具有很多属性的对象的实例化可能需要几行（不知道这是否真的是一个缺点），如果我忘记设置一个属性，编译器不会说什么。

你会做什么，为什么？您是否知道建议的任何灯光模式（考虑到每次实例化具有 7 个以上属性的对象时都应该使用它）？我问这个是因为我倾向于不喜欢大型构造函数，因为我无法快速找出我正在寻找的变量在哪里，另一方面，我发现“设置所有属性”容易丢失一些属性。

请随意争论我的假设的利弊，因为它们只是我的想法:)

更新 - 我发现的一个与此相关的问题：Building big, immutable objects without using constructors having long parameter lists

【问题讨论】：

标签： java constructor setter

【解决方案1】：

您错过了拥有带有大量参数的构造函数的最大优点：它可以让您创建不可变类型。

创建不可变类型的正常方法没有巨大的构造函数是有一个辅助类型 - 一个builder，它维护你在最终对象中想要的值，然后在您准备好时构建不可变对象。

【讨论】：

建造者难道不是更好的策略吗？
另外，如果你的对象的状态不能在没有设置属性的情况下运行，那么强制用户通过构造函数来设置它们。
@Uri：如果您只有几个属性，那么构建器模式在 IMO 之上。
@Jon Skeet：感谢您指出不可变类型的存在，我不知道它们。
@Jon Skeet 是正确的。这些天，我实际上认为建筑商之外的二传手是一种难闻的气味。不可变类通常更容易推理，而在并发环境中更容易推理。 Builder 模式（它与使用 setter 共享）的一个缺点是它不适用于缺少默认值的属性。您可以在调用 build() 时检查是否已设置所有必需的属性，但是您谈论的是运行时检查而不是编译时检查。太糟糕了 Java 没有关键字参数。

【解决方案2】：

最近关于 API 可用性的学术研究（CMU 和 Microsoft）表明，使用 setter 的默认构造函数将是可用性方面的最佳选择。这是来自 Jeff Stylos 和 Steven Clarke 的“对象构造函数中要求参数的可用性影响”，并在国际软件工程会议上发表：

Abstract: API 的可用性对程序员的生产力越来越重要。基于对特定 API 的可用性研究的经验，探索了用于研究许多 API 共有的设计选择的可用性的技术。进行了一项比较研究，以评估专业程序员如何在对象的构造函数中使用具有所需参数的 API，而不是无参数的“默认”构造函数。据推测，通过引导程序员正确使用对象和防止错误，所需的参数将创建更多可用和自记录的 API。然而，在研究中发现，与预期相反，程序员强烈倾向于使用不需要构造函数参数的 API 并且更有效。使用认知维度框架对参与者的行为进行分析，发现所需的构造函数参数会干扰常见的学习策略，从而导致不良的过早承诺。

【讨论】：

【解决方案3】：

您可以查看 Joshua Bloch 倡导的 Builder 模式，并在 Effective Java 中进行了描述。在http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2689.pdf 有一个介绍要点；毫无疑问，您可以找到更好的参考。

基本上，您还有另一个类，可能是一个内部类，它提供以设置的属性命名的方法，并返回原始构建器，以便您可以链接调用。它产生了相当可读的代码块。

例如，假设我有一个简单的Message，其中包含一些属性。构建它的客户端代码可以使用构建器来准备Message，如下所示：

Message message = new Message.Builder()
    .sender( new User( ... ) )
    .recipient( new User( ... ) )
    .subject( "Hello, world!" )
    .text( messageText )
    .build();

Message.Builder 的片段可能类似于以下内容：

public class Builder {

    private User sender = null;
    // Other properties

    public Builder sender( User sender ) {
        this.sender = sender;
        return this;
    }
    // Methods for other properties

    public Message build() {
        Message message = new Message();
        message.setSender( sender );
        // Set the other properties
        return message;
    }

}

【讨论】：

如果您有一个复杂的对象，构建器非常好。我强烈推荐它。
还有这本书！对于 Java 程序员来说，这确实是一本必读的书——它可以在我阅读它的 O'Reilly Safari 上找到（我们的订阅量最小）
您还可以让构建器对象实现多个接口，每个接口都有一个方法返回包含下一个方法的接口，因此您必须按预定义的顺序调用所有构建器方法，并且只能调用 build () 一旦所有的 setter 都被调用...
有趣的想法，那个。就个人而言，我尽量避免在给定对象中包含过多的强制属性，并且我倾向于以这样一种方式使用 Builder 模式，即我使用属性命名的方法来设置可选属性，但它当然可以是有趣的选择。当然，如果客户端没有设置所有必需的属性，你可以直接抛出 IllegalStateException。

【解决方案4】：

还有其他方面。如果您希望能够在设计时而不是仅在运行时对类进行某些操作，例如将您的类添加为对象面板中的对象（这是使用 Netbeans 的 Java），您需要在为了能够这样做。

【讨论】：

这是一个重要的考虑因素——ORM 工具（例如 Hibernate，虽然我不确定最新版本是否仍然如此）往往需要可访问的 setter 和默认构造函数。

【解决方案5】：

您在帖子中提到了它，但我认为这是值得更多关注的重点：除非每个输入参数都是不同的类型，否则大型构造函数的最大问题是它非常容易转置几个变量。编译器是一个不可靠的安全网——它会捕捉到一些错误，但漏掉的错误将更难以识别和调试。特别是因为一个巨大的构造函数的输入列表是非常不透明的，除非你在另一个窗口中打开了 API。

Getter 和 setter 更容易调试，尤其是如果您制定了在对象未正确填充时引发运行时异常的安全措施。而且我是“易于调试”的忠实拥护者。

在此线程之前，我从未听说过 Rob 提到的 Builder 模式。我自己从未使用过它（显然），但它非常有趣。

【讨论】：

如果对象没有正确填充，一个机构如何保障抛出运行时异常？

【解决方案6】：

这里还有其他策略。在试图弄清楚如何处理大量参数之前，我认为重新审视你的设计并看看你的类是否做得太多是很重要的。看看您是否可以将一些参数组合到一个新类中，并将一些行为移到该类中。

【讨论】：

【解决方案7】：

setter 和默认的空构造函数

JRL obliquely touched on it，但考虑使用 setter 的一个原因是让对象符合 JavaBean specification。这使得实例可以通过自省工具和使用某些serialization techniques 的持久性来适应editing。

【讨论】：

【解决方案8】：

出于上述不变性的原因，我更喜欢使用构造函数参数。如果这为您提供了一个带有大量参数（比如说超过四个左右）的构造函数，那对我来说就是一种代码味道：其中一些参数应该捆绑在一起成为它们自己的类型。

例如，如果你有这样的事情：

class Contact
{
    public Contact(string firstName, string lastName, string phoneNumber,
        string street, string city, string state, int zipCode) { ... }
}

我会将其重构为：

class Contact
{
    public Contact(Person person, PhoneNumber number, Address address) { ... }
}

class Person
{
    public Person(string firstName, string lastName) { ... }
}

class PhoneNumber
{
    public PhoneNumber(string digits) { ... }
}

class Address
{
    public Address(string street, string city, string state, int zipCode) { ... }
}

过大的类是 OOP 代码库中非常常见的设计问题。

【讨论】：

邮编可选怎么处理？
重载地址的构造函数。

【解决方案9】：

谁说你不能两者兼得？我想说强制属性进入构造函数，可选属性由设置器处理。顺便说一句，谁说每个属性都需要一个二传手？如果两个属性在概念上属于一起，为什么不将它们设置在一起呢？

我也喜欢 Builder 模式，但最重要的规则是：始终动脑筋，找到最适合特定问题的设计。没有万能的解决方案。

【讨论】：