在java对象中有构造函数更改时的最佳实践

我有一个类，其中许多参数正按照新的api集成进行添加。在java对象中有构造函数更改时的最佳实践

例如，早些时候，我曾与4个参数的类：

Integer a; 
String b; 
Map<String, String> c; 
List<Integer> e.

这样的构造是：

public SampleClass(Integer a, 
        String b, 
        Map<String, String> c,  
        List<Integer> e) 
{ 
    this.a = a; 
    this.b = b; 
    this.c = c; 
    this.e = e; 
}

几个队都在他们的代码中使用此构造我的API集成。过了一段时间，这个类中增加了一个新参数。即

Double d;

所以我增加了一个新的构造：

public SampleClass(Integer a, 
        String b, 
        Map<String, String> c, 
        List<Integer> e, 
        Double d) 
{ 
    this.a = a; 
    this.b = b; 
    this.c = c; 
    this.e = e; 
    this.d = d; 
}

而且标志着我以前的构造函数弃用。我没有删除以前的构造函数，因为如果删除了，客户机的代码就会中断。

随着新参数的增加，我现在有5个参数的构造函数。

是否存在关于如何构建器应该被弃用/移除的最佳做法，以避免发生这种类型的场景？

来源

2016-05-16 SIDDHARTH J MEHTA

不确定这是否是一个好主意，但您可以尝试使用[Lombok]（https://projectlombok.org/features/Builder.html）构建器模式。唯一的问题（我不知道这是否是你的答案）是Lombok依赖于这种实例是以这种方式创建的：'Type.builder.param1（valueParam1）.others（valueOthers）。（...）.. 。（...）。build'，这是你以前的客户没有的东西。但是，如果你与他们谈判，他们不能这样做吗？我的意思是龙目岛给你一个自我管理的构造函数，它独立于params的顺序并且独立于数字。 –

使用'builder Pattern'并在当前类中使用'overloading' for构造器 – Hosseini

可能重复的[为方法传递许多参数的最佳实践？]（http://stackoverflow.com/questions/2432443/best-practice-for-传递许多参数到方法） – Joe

-2

为什么你不使用变量参数构造函数。这样你就可以将许多参数传递给构造函数。

例如：

公共双平均值（双...号）{

 double total = 0.0; // initialize total 

     // calculate total using the enhanced for statement 
     for (double d : numbers)    
     total += d;       

     return total/numbers.length; 
    } // end method average

来源

2016-05-16 09:10:30 ramasCoder

请原因Please ???????? – ramasCoder

答案与问题不符。 –

请详细说明。在我看来，它确实匹配。 – ramasCoder

改变旧的构造来自：

public SampleClass(Integer a, 
        String b, 
        Map<String, String> c,  
        List<Integer> e) 
{ 
    this.a = a; 
    this.b = b; 
    this.c = c; 
    this.e = e; 
}

到

public SampleClass(Integer a, 
        String b, 
        Map<String, String> c,  
        List<Integer> e) 
{ 
    //Zero is passed as a default value, but you can pass anything you want 
    this(a,b,c,e,0); 
}

这它会加州的方式在发动机罩下新的一个。

尽管如此，你还是没有提供足够的信息，应该在多大程度上支持旧的。如果它不应该，你应该从代码中删除它。这样你会强迫API的用户分析什么改变和电线新构造。

如果你不这样做，他们将继续使用旧的，因为程序员的懒惰 :-)

来源

2016-05-16 09:11:16 Kelevandos

这与懒惰无关。当你发布一个API时，你做出了承诺。履行这个承诺是你的责任。 – biziclop

是的，但是如果API必须改变并且确实发生了变化，程序员应该负责并分析在更新到新版本时发生了什么变化。实际上，如果代码编译和测试通过，我们大多数人会简单地认为没有任何变化。而@Deprecated对于抵制这种做法没什么作用：-D因此，如果这种改变出于某种原因至关重要，那么从API中移除方法是表明用户应该分析改变的原因和原因的一种好方法。如果他们不愿意，因为他们现在信任API，他们总是可以避免更新，以新功能和更改等为代价。C'est la vie – Kelevandos

您只希望对主要版本更改进行必要的API更改那是公约。正如我在另一个评论中所说的，重要的是，您对如何处理这样的实例有非常明确的政策。 – biziclop

遵循Open/closed principle将是有益的。当需要新功能时，最初编写的类不应该被修改，而应该从中派生另一个类来扩展其功能。

来源

2016-05-16 18:51:36 iluwatar

但随着新参数逐渐增加，不会创建新类。管理所有这些类会不会很困难？ –

在java对象中有构造函数更改时的最佳实践

回答

相关问题