的雖然有不少Q &的作爲與IDisposable要在SO發現，我暫時還沒有發現一個答案：明確實施了IDisposable
我通常遵循慣例，當一個我類擁有一個IDisposable對象，那麼它也執行IDisposable並在擁有的對象上調用Dispose。但是最近我遇到了一個明確實施了IDisposable的課程，因此阻止我直接調用Dispose，迫使我將其投入使用，這讓我感到煩惱和不必要。
所以這個問題：爲什麼和什麼時候會想要使用明確的接口實現IDisposable？我知道明確地實現一個接口有完美的和有效的理由，但是關於IDisposable，原因對我來說不是很清楚。
我想說除非你有一個替代的等價方法（例如關閉），否則顯式實現IDisposable.Dispose是不常見的。
在這種情況下，您的包裝類可以調用Close而不是cast。
一個示例是Framework < = V3.5中的WebResponse類。有趣的是在.NET 4中有一個公共的Dispose方法，所以也許微軟現在已經決定明確的實現可能不是好的做法。
肖恩·法卡斯，在CLR安全團隊的設計工程師中寫道MSDN magazine這
雖然使用塊將帶班的工作，確實有一個明確的IDisposable實現，我建議階級是不會實現的接口這辦法。如果你明確地實現IDisposable，開發商誰正在探索在視覺工作室使用的IntelliSense®對象模型不會注意到對象具有Dispose方法
事實上，我想包裝的課程暴露了我最終使用的「Close」方法。只是提供的示例代碼顯式包含了：'SomeClass o = new SomeClass（））'，因此很明顯鼓勵使用一次性模式。 – ChrisWue 2011-04-07 07:44:48
我會說這是很好的做法，它迫使（除非你想轉換爲IDisposable的!!）使用使用
using (ClassWithIDisposable) {
}
處置甚至會在出現異常的情況下，使用國際奧委會框架，如城堡，你最終不得不繼承IDisposable接口統一時，被稱爲
而且你界面，所以它可以被調用。這些框架允許AOP，因此你沒有參考你的固體類只有一個接口......
恕我直言，只有一個正確的原因，一個類明確實現IDisposable，這將是如果它是預計沒有人會真的需要這樣做。一個類明確實現了IDisposable的事實可以被看作是一個指標，可以安全地創建一個對象那個特定的類，儘管不一定是派生類的對象，並且在完成它時簡單地拋棄它。缺少對特定類的直接可用的Dispose方法可能會被視爲一個指示器，因爲不需要對已知爲該特定類的對象調用Dispose。
請注意，具有並使用對實現IDisposable的對象的引用，而不會意識到它的作用，這不是問題;然而，獲得這樣的對象的所有權。返回類型對IDisposable不起作用的工廠方法。明確地處理和實現它，但有時會返回一個期望正確處置的對象，這將成爲泄漏的祕訣。如果一個類可能被用作這種工廠方法的返回類型，則不應該顯式實現IDisposable。
就我個人而言，我的傾向是放棄實現IDisposable的所有對象，無論他們是否需要它。儘管如此，如果知道某些特定類型的IDisposable對象在確保妥善處置的情況下可能非常有用，否則這種情況會很困難或尷尬。
這些「好的和有效的原因」是什麼，爲什麼他們不應該支持'IDisposable'呢？爲什麼將一個對象投射到「IDisposable」是「煩人的」？ – chiccodoro 2011-04-07 07:09:44
有時，類有必要實現兩個或更多個成員名稱衝突的接口。對於明確的界面命名來說，這是一個很好且適當的用法。我同意OP的意見，任意命名清理方法的東西除Dispose之外是愚蠢的。即使一個類有一個Close方法，這並不意味着它也不應該有一個Dispose方法。由於在調用Close之後調用Dispose的情況最差，所以這兩種方法有什麼不對？ – supercat 2011-04-07 07:21:41
@chiccodoro：IMO顯式接口實現大多在需要實現兩個具有衝突成員的接口時非常有用。在任何其他情況下，如果有一個對象可以轉換爲接口而不是「存在」，那麼該接口是不自然且令人討厭的。 – 2011-04-07 07:22:30