確定返回內部列表<T>作爲IEnumerable <T>或ICollection <T>？

Question

可能重複：
Collection<T> versus List<T> what should you use on your interfaces?

考慮這個方法，返回的變量myVar是List<T>，但該方法MyMethod()的返回類型是IEnumerable<T>：

public IEnumerable<T> MyMethod(string stuff) 
{ 
    var myVar = new List<T>(); 
    //do stuff 

    return myVar; 
} 

本質上，我想知道的是如果returni ng myVar作爲不同的類型是可以的。

具體而言，就我的情況而言，'do stuff'會經過DataRow並將該DataRow中的項目分配給對象列表。在其他地方，我也有類似的情況與ICollection和IList返回類型。

我想退回IEnumerable或ICollection的原因是，我沒有回覆超過需要。但是同時，如果需要的話，這允許調用者將返回值轉換爲List。

但是，我的返回語句返回List而不是方法的返回類型是奇怪的。這是正常的做法嗎？這樣做有什麼問題嗎？

澄清（響應欺騙評論）：

只是爲了澄清，我很好奇的是，如果它是好的，在我的身體return語句返回一個List<T>，但該方法標題有返回類型IEnumerable，或可能有ICollection,Collection等等......有些東西不同比比例返回聲明。

Answer 1

不僅沒有錯，它實際上是一個好習慣：只暴露嚴格必需的東西。這樣，調用者不能依賴於該方法將返回List<T>的事實，所以如果由於某種原因需要更改實現以返回其他內容，則不會違反合同。但是，如果（錯誤地）對該方法實際返回的假設做出了假設，則調用代碼可能會中斷。

Answer 2

它沒有問題。

實際返回具體類是滿足「返回接口」要求的唯一方法。

如果您讓特定類的知識潛入調用代碼（List<T> r = (List<T>)MyMethod("ff")），可能會有缺點。但是如果你把結果當作接口（如你所想的那樣）就沒關係。

Answer 3

返回IEnumerable<T>類型的原因是，它們調用者無法修改列表（而不是將其重新轉換爲列表）。如果您注意到所有（大多數？）擴展方法採用IEnumerable<T>參數，以便您知道該擴展方法不會修改您的列表。其次，List<T>繼承IEnumerable<T>。

編輯： 正如托馬斯在評論該IEnumerable<T>可以被調用者轉換回一List<T>和修改的解釋。如果您的主要目標是使其成爲只讀，您可以返回列表myVar.AsReadOnly()。但是那種類型是ReadOnlyCollection<T>。

Answer 4

我認爲這不是最優的，因爲它允許調用者投射到List<T>，這依賴於實現細節。我會添加一些掩碼，例如Select(x=>x)。

一個動態類型的調用者可能甚至不會注意到您將您的列表投射到IEnumerable<T>。對他來說簡直就是List<T>。

返回一個內部永久List<T>爲IEnumerable<T>將是非常錯誤的，因爲它允許調用者改變你的類的內部狀態。但是，由於您在每次調用中都返回一個新的List<T>實例，因此在其他地方沒有使用該實例，因此該示例中不適用此參數。