在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對象中有構造函數更改時的最佳實踐

回答

相關問題