繼承或包裹一類併發

優惠試圖提供的ConcurrentQueue<T>單位可測試（使用MOQ）抽象我辯論我是否失去了使用框架的ConcurrentQueue<T>實現取決於我如何創作抽象的好處。繼承或包裹一類併發

什麼是做一個或另一個在下面的代碼清單的影響：

public abstract class MyMessageQueue1<T> : ConcurrentQueue<T> 
{ 
    public new virtual void Enqueue(T item) 
    { 
     base.Enqueue(item); 
    } 
} 

public class MyMessageQueue2<T> 
{ 
    private readonly ConcurrentQueue<T> _concurrentQueue = 
     new ConcurrentQueue<T>(); 

    public virtual void Enqueue(T item) 
    { 
     _concurrentQueue.Enqueue(item); 
    } 
}

在首次執行（MyMessageQueue1），我隱藏任何的基類的方法來傳遞前提供我的實現對基類的調用。

在第二個執行，我包裹ConcurrentQueue<T>裏面，當我需要傳遞給它的調用。

MyMessageQueue2是否必須手動處理併發或不重要，因爲所有調用都傳遞給包裝的ConcurrentQueue<T>。

來源

2012-11-02 leon

爲什麼你真的這樣做，你想達到什麼目的？ –

+1結束成爲一個好問題@TrevorPilley – leon

你不必處理併發在這兩種情況下，因爲你要做的只是委託給ConcurrentQueue電話爲已被@nanda說明。但是，這將有助於我們瞭解你的理由來包裝這門課。這是相當單元測試友好的，因爲它不使用任何外部資源，如文件或數據庫。在你的類中使用時，你可以讓它完成它的工作，而是測試你使用ConcurrentQueue的自己的功能。

如果您試圖封裝它，因爲您想驗證您的方法是否以期望的方式使用它，那麼您可能只關注測試方法的實現而不是方法的行爲。這在某些情況下可能有用，但您必須注意這一事實，這不是一種常見做法。

有一件事寫這樣的包裝時，你正在失去。由於包裝器具有虛擬方法，因此它們可能會被模擬，所以方法不能被內聯，並且會失去一點性能。 ConcurrentQueue是苗條和快速的類，這可能實際上是一個問題。

來源

2012-11-05 10:43:46

謝謝。在詢問實際意圖時，你和@nanda讓我質疑自己，最後我不需要測試ConcurrentQueue實現。我確實只測試了類的_design_而不是*行爲*。所以，+1給你們兩個。我將這個標記作爲答案，因爲它增加了nanda所說的，增加了該方法的測試實現並不總是必要的。 – leon

如果所有的包裝確實是代表團ConcurrentQueue，以及包裝不具有它自己的成員，以保護爲併發訪問那麼就沒有什麼併發爲你包裝工作要做。

但是，你會在這個薄包裝單元測試？

來源

2012-11-02 12:04:20 nanda

繼承或包裹一類併發

回答

相關問題