不變性和一般與特定類型

這是在創建接口/ API的上下文中。最佳做法建議在界面中使用常規而不是特定類型 - 例如， Map而不是HashMap。最佳做法還建議寧願使用不可變類型而不使用可變類型。不變性和一般與特定類型

因此同時考慮這些建議（和撇開關於性能/內存佔用，第三方的庫/依賴性和便利性/功能問題）應該在一個公共接口看起來像這樣

public List<SomeClass> someMethod(...)

的方法

或者更確切地說，本

public ImmutableList<SomeClass> someMethod(...)

來源

2014-02-26 Dexter

如果返回的List保證是不可變的，它應該看起來像2），否則它應該看起來像1）。什麼是不可變列表btw？如果我不能添加它，它真的是一個List？ –

第一個......請注意，不可變的_collection_並不意味着_elements_的不可變性;它只是意味着你不能改變集合本身（替換/刪除/添加元素）。 – fge

@JohnRasch哦，好的，謝謝。我最近沒有真正考慮過或遇到過這個概念。 –

當這已經在番石榴人之間的討論，下面已經說：

API交換類型的基本建議是：選擇仍然傳達相關語義信息的最一般類型。

我認爲ImmutableCollection所做的三種語義保證與幾乎任何情況下的返回值都非常相關（這三種是不變性，缺少空元素和保證迭代次序）。所以我幾乎總是會返回ImmutableSet，而不是Set。

我們真的很喜歡人們將ImmutableSet等視爲每個重要意義上的界面。只有兩個原因，它們不是：不變性保證的可靠性，以及Java在JDK 8之前不會允許接口上的靜態方法，並且爲了方便，我們希望它們在那裏。

大多數人認爲ImmutableList是這個原因的一個實現，但實際上有幾十種不同的這些類型的一些實現;你只是看不到它們。

來源

2014-02-26 23:52:49

如果方法的合約保證List不可變，那麼返回類型應該是ImmutableList而不是List。這比簡單地提到列表在方法的JavaDoc中不可變更明確得多。

但是，如果列表的不變性是實現細節而不是合同，那麼返回類型應該是List。

來源

2014-02-26 23:54:04

編寫API是關於與用戶簽訂合同。

最佳實踐主要針對需要爲第三方編寫API並需要定義接口的上下文。

我們可以在不同的環境下有不同的觀點。如果您正在編寫將由第三方使用的庫，則需要考慮它們是否應該更改對象狀態。

如果API將在內部使用（使用相同的代碼庫）&的目的是實現鬆耦合，那麼您需要考慮易於編寫，可擴展性和可維護性。

不可變的API可以避免數據不一致性，特別是當您對對象狀態做出很多假設時。另一方面，可變對象可以節省開發工作。

來源

2014-02-27 18:33:23

不變性和一般與特定類型

回答

相關問題