關於返回類型與集合

在我的BL（將是一個公共API），我使用的ICollection在我的查找方法的返回類型，如問題<>。關於返回類型與集合

現在在我的GUI，我需要轉換的結果反饋給收藏，如：

Collection<Customer> customers = (Collection<Customer>)BL.FindCustomers();

這是因爲我需要使用一些收藏<>具體方法我返回的列表，這是我不能做與ICollection <>。

這是正確的用法嗎？或者，我應該簡單地將收益類型從收集<>改爲收回<>以避免此轉換？

其次，我沒有使用IEnumerable，因爲它比ICollection更通用，甚至沒有像Count這樣簡單的屬性。我真的沒有看到在這裏歸納返回類型的一個觀點。我錯過重要的東西嗎？

來源

2009-08-12 Raghav

使用ICollection的重點是更通用，隱藏更多信息，這是一件好事。

但是，如果您需要將其轉換回來，它已變得毫無意義，您不妨返回更具功能的Collection <>。

來源

2009-08-12 20:34:58

返回ICollection的想法是讓你的在你的方法上有更少的耦合。如果你想稍後建立一個列表，而不是一個集合，你可以在不破壞客戶端代碼的情況下完成它。

如果你使用這只是爲了得到一個集合（而不是ICOLlection），比恕我直言，你可以改變爲集合，知道你會有一個不太靈活的方法。但無論如何，YAGNI。

此外，如果您擔心設計，我建議不要將此靜態編碼爲improve the testability您的代碼。

來源

2009-08-12 20:32:58

這可能是因爲Collection實現了IList，它有一些額外的ICollection沒有的方法，對於你來說是IList。你錯過了哪些方法？

來源

2009-08-12 20:34:24

如果您要求您的用戶使用Collection <>的方法，則應該返回Collection <>而不是ICollection。

或者可能使用具有獨立的功能，它是內部的組件返回您需要爲您的GUI類型：

internal static ICollection<Customer> FindCustomers() 
{ 
    Collection<Customer> customers = DAL.GetCustomers(); 

    return customers; 
}

來源

2009-08-12 20:37:45 Valentein

你想返回的ICollection的唯一原因是鬆耦合和繼承的效果影響不大。如果你的方法只有1個版本（因爲它的靜態）你總是知道返回類型（Collection），並且不需要將它作爲ICollection。然而，如果你在一個類族中使用，可能有一個返回和ICollection的虛擬或抽象方法，那麼在子類實現中，可以返回一個Collection或FunkyCollection或任何實現該接口的對象，所以這給你一個說更多的靈活性，說你只能返回一個集合。但爲了您的目的，您應該擴展只是返回類型集合而不是ICollection，因爲它是一種不會被重寫的靜態方法。它也不會導致用戶混淆，因爲他們不需要投射。

來源

2009-08-12 20:41:54 Daniel

其他人都已經給出了這麼好的答案，但我只是想澄清一下，不，我不相信你在做什麼是理想的。其原因是，如果稍後有人出現並修改/重構/重新實現BL以返回其他類型的ICollection（根據API），那麼這不是Collection，您將在GUI中得到運行時錯誤。然後，如果你真的想要一個Collection（可能，對於一個或多個方便的擴展方法，我猜測？），那麼你可以選擇返回ICollection創建一個新的集合並將內容從一個複製到另一個。這樣，你不會冒着運行時錯誤的風險。雖然，它最終取決於（作爲別人已經問過的）你在Collection中尋找哪種方法（或許有更好的方法來做你想做的事情）。

祝你好運！
-f！

來源

2009-08-12 21:02:46 Funka

關於返回類型與集合

回答

相關問題