没有参数的构造函数或参数构造函数

Question

在我的程序中，我读取一个固定长度的文件，将每个字符串存储在局部变量中，然后将每个值存储到类类型数组列表中。为了创建数组列表的对象，我使用了所有变量的参数构造函数。下面的代码演示了这一点。

String a = "text1"; 
String b = "text2"; 
SampleModel sm = new SampleModel(a,b); 
ArrayList<SampleModel> sampleList = new ArrayList<>(); 
sampleList.add(sm); 

我觉得这是绝对正确的，但我的同事要求我将其更改为无参数构造函数，并调用getters和setter。那将如下所示。

SampleModel sm = new SampleModel(); 
ArrayList<SampleModel> sampleList = new ArrayList<>(); 
String a = "text1"; 
String b = "text2"; 
sm.setA(a); 
sm.setB(b); 
sampleList.add(sm); 

是否有任何理由更喜欢参数构造函数的无参数构造函数？ （我的程序有大约15个变量）

Answer 1

这取决于如何使用该类。

例如，一个不可变类将需要一个构造函数，该构造函数接受参数，并且不需要setter。

但是一个Java Bean将需要一个无参数的构造函数和setters。

有些事情要考虑：

• 胶囊化可以是有价值的。除了像JavaBeans这样的特殊情况，通常可以根据所需的交互来设计类的接口，而不是基于当前的数据成员集。
• 方法有名称。 Java不支持命名参数。方法名称在调用代码中传递实际参数的使用方式。如果你的类有很多参数，通过方法传递它们会导致更具可读性的调用代码。
• 不可变类具有价值。如果你直接在你的类中添加命名setter，它不会是不可变的。构建器模式允许您接受构建参数，即使对于不可变类也是如此。

Answer 2

接受参数的构造函数实质上是为了方便（尽管如果对象需要参数才能被正确构建，情况并不总是如此）。它的做法与set方法完全相同。

只要这些参数在对象上下文中“有意义”，没有理由没有构造函数接受参数。换句话说，它不仅仅是一个正确的东西，而是一个语义学的东西。

如果构造是：

public SampleModel(String a, String b) 
{ 
    this.a = a; 
    this.b = b; 
} 

它可能不会有所作为。

Answer 3

无论我用存取函数的一类变量取决于两个因素：

1. 变量是否是必要的或可选的对象。
2. 它是否可能在使用该对象的过程中发生变化，或者是否为final。

必要和最终的变量应该在构造函数中，在我看来，不应该有变异函数。变量是可选的，应该有访问器和增变器。重要但可能会改变的变量取决于您的判断。我可能会把它们放在构造函数中，但使用Builder设计模式来避免构造函数有一长串参数。

Answer 4

这可能只是因为比拥有大的逗号分隔列表更容易看到发生了什么。这也可能是使用双大括号初始化一个不错的地方：从福勒和贝克书

String a = "text1"; 
String b = "text2"; 
SampleModel sm = new SampleModel() {{ 
    setA(a); 
    setB(b); 
}}; 
ArrayList<SampleModel> sampleList = new ArrayList<>() {{ 
    add(sm); 
}}; 

Answer 5

报价：“重构”

长参数列表

在我们早期的节目里，我们都教导传递作为参数所需的一切例程。这是可以理解的，因为替代方案是全球数据，全球数据是邪恶的，通常是痛苦的。对象改变了这种情况，因为如果你没有你需要的东西，你总是可以要求另一个对象为你得到它。因此，使用对象时，您不会传递该方法所需的所有内容;而是通过足够的方法，以便该方法可以达到所需的一切。该方法的主机类有很多方法需要。在面向对象的程序中，参数列表往往比传统程序小得多。这很好，因为长参数列表很难理解，因为它们变得不一致并且难以使用，并且因为您需要更多数据而永远改变它们。大部分更改都是通过传递对象来移除的，因为您很可能只需要发出几个请求来获取新的数据。如果您可以通过提出您已知的对象的请求来获取一个参数中的数据，请使用替换参数和方法。这个对象可能是一个字段，或者它可能是另一个参数。使用保留整个对象从对象中搜集一堆数据，并用对象本身替换它。如果您有几个数据项没有逻辑对象，请使用引入参数对象。进行这些更改有一个重要的例外。这是当你明确不想创建从被调用对象到更大对象的依赖。在这些情况下解包数据并将其作为参数发送是合理的，但要注意所涉及的痛苦。如果参数列表太长或者经常更改，则需要重新考虑依赖关系结构。