在構造函數中使用許多參數的性能

是否有人知道在使用構造函數（10+）中的許多參數時與設置程序相比對性能有何影響？在構造函數中使用許多參數的性能

我的情況模型對象是無效的沒有任何這些參數，所以我使用單個構造函數。

我知道這兩種方式都沒有顯着差異，但我問是否有人知道兩種情況下實際發生了什麼。

我在詢問性能，因爲該應用程序是可以在沒有JIT的舊設備上運行的Android應用程序。

此外，如果我們知道最佳解決方案，這將是很好的。

2012-02-17 peceps

你爲什麼不寫一個測試，並測量自己？ – 2012-02-17 14:17:21

正如您所說，在性能方面沒有顯着差異。然而，在封裝和正確性方面，存在顯着差異。 – 2012-02-17 14:17:46

處理4+參數時使用生成器模式。 – 2012-02-17 14:19:49

使用setter與構造函數的性能影響可以忽略不計，因爲在這兩種情況下都會發生大致相同的事情：傳遞給方法的數據將存儲在實例變量中。

有十個setter可以支付9個附加方法調用的價格，但它們非常便宜以至於您不可能找到任何區別，特別是如果它們被JIT編譯器內聯。

邏輯影響更加嚴重：如果在設置所有十個實例變量之前對象無效，那麼您肯定需要使用帶有十個參數的構造函數：性能增益（實際與否）是次邏輯班級的完整性，這不應該受到影響。

2012-02-17 14:20:48 dasblinkenlight

+1回答問題。 – 2012-02-17 16:08:02

我同意這個答案。吸氣劑在帶有JIT的設備上很便宜，但一次沒有那麼多。與僅使用構造函數相比，每調用15000次getter調用，我測量的差異大約爲1秒。 – peceps 2012-02-20 13:31:45

您可以將所有參數封裝在一個對象中，並將其作爲參數傳遞給您的構造函數。

2012-02-17 14:18:47 adranale

這不會解決任何問題。因爲封裝對象必須以相同的方式創建。通過這樣做，問題沒有解決，它只是轉移到另一個班級。 – 2012-02-17 14:22:45

@SoboLAN爲什麼它必須以相同的方式創建？您可以逐步構建這樣的對象，並最終將其傳遞給構造函數。儘管如此，構建器模式更加靈活，但是在調用構建器的方法並最終調用build（）方法時會做類似的事情。兩者都在收集最終創建對象所需的數據。 – 2012-02-17 14:46:52

@FabianBarney該死的，忘記了構建模式。是的，那會起作用。 – 2012-02-17 15:52:41

在大多數情況下，如果你有這樣的情況，這就清楚地表明你的代碼需要（一些）重構。這兩種解決方案都不是很好（即構造函數與setter中的大參數列表）。另外，考慮到您無法強制該對象的客戶端調用setter，因此可能會發生一些運行時錯誤。

至於表現部分：不，性能影響不會因此而發生。沒有理由爲什麼它應該。

2012-02-17 14:21:51

在某些情況下，一個大參數列表是正確的。如果你在構建你的對象時知道它們，那麼它就不會被分成更少的對象，只需要做。我見過保險合同課，有更多的屬性。 – 2012-02-17 15:35:08

我同意這種說法，即由於您提到的原因，制定者對這種情況不利。我不同意重構部分，有時候帶有許多參數的構造函數正是需要的。可能現在最好的解決方案是建造者模式。 – peceps 2012-02-20 13:33:16

回答