2012-02-13 68 views
3

通常,您必須實現集合,因爲它不存在於.NET Framework的集合中。在我在網上找到的例子中,新集合通常是基於另一個集合(例如,List<T>)構建的:通過這種方式,可以避免管理集合的大小調整。使用另一個集合實現集合

public class CustomCollection<T> 
{ 
    private List<T> _baseArray; 

    ... 

    public CustomCollection(...) 
    { 
     this._baseArray = new List<T>(...); 
    } 
} 
  1. 什麼是以下這種方法的缺點?由於對基礎集合的方法調用只會降低性能?或者編譯器執行一些優化?
  2. 此外,在某些情況下,與基本集合有關的字段(例如上面的_baseArray)被聲明爲readonly。爲什麼?
+0

我不明白這一點:「通過這種方式,可以避免在整個問題的背景下調整集合大小的管理」。 – Joe 2012-02-13 01:31:28

+0

@Joe:我認爲他指的是使用列表而不是普通數組。 – 2012-02-13 01:33:31

+0

@Joe:爲了調整一個普通數組的大小,我必須創建另一個新大小的數組,然後將這些元素複製到新數組中,然後銷燬舊數組......如果我使用List,這些操作是透明的。 – enzom83 2012-02-13 01:35:29

回答

3
  1. 的主要缺點是,如果你想發揮好,你就必須用手工來實現很多的接口(ICollection的,IEnumerable的,可能的IList ...通用和非通用),和這是相當多的代碼。不是複雜的代碼,因爲你只是中繼呼叫,但仍然是代碼。在大多數情況下,對內部列表的額外呼叫不應該有太大差異。
  2. 這是爲了強制這樣一個事實,即一旦設置了內部列表,它就不能更改爲另一個列表。

通常最好從許多內置的集合類,使自己的收藏之一繼承,而不是做了艱辛的道路。 Collection<T>是一個很好的起點,沒有人阻止你繼承List<T>本身。

+0

不從'List '繼承' - 它的方法沒有被聲明爲虛擬的,所以這是一個不可行的方法 – BrokenGlass 2012-02-13 01:37:37

+0

@BrokenGlass:如果你不需要覆蓋它們中的任何一個,這不是一個不行。有時,使用具有列表的確切功能的集合以及一些方法很有用。當然,如果您需要更改內置方法的功能,則使用「Collection 」類。 – 2012-02-13 01:39:33

+1

這不完全是'readonly'的意思。你*可以*設置它多次,但只能從構造函數或字段初始值設定項中設置。 – svick 2012-02-13 14:47:33

2

對於#2:如果私人成員只在構造函數中分配或聲明時,它可以是readonly。如果您只有一個基礎集合並且不需要重新創建它,通常情況下就是這樣。

+0

因此,如果我在某些方法/屬性中錯誤地重新創建列表,編譯器會報告錯誤:從這種類型的錯誤中增加一種安全形式? – enzom83 2012-02-13 01:49:21

+1

是的,儘管我通常不把它看作是一個安全問題,而是一個設計問題。我不希望集合被替換,所以我用'readonly'來執行它。在某些用戶不想要的情況下(例如,大規模刷新,在從外部源加載後用新的集合替換舊集合...)) – Joe 2012-02-13 02:05:22

-1

我想說這種方法的一個很大的缺點是你不能在你的自定義集合上使用LINQ,除非你實現IEnumerable。一個更好的辦法可能是子類,並迫使新方法執行必要的,例如:

public class FooList<T> : List<T> 
{ 
    public new void Add(T item) 
    { 
     // any FooList-specific logic regarding adding items 
     base.Add(item); 
    } 
} 

對於readonly關鍵字,這意味着你可以只設置在構造函數的變量。

+1

從'List '繼承是一個壞主意 - 你的例子顯示了爲什麼 - 基本方法不是虛擬的,所以你所做的只是隱藏基類方法,這根本就不是一個可靠的解決方案。 – BrokenGlass 2012-02-13 01:38:48

相關問題