为什么Hashtable实现ICollection和IEnumerable？

Question

在.NET Framework 3.5（C＃3.0）中，为什么System.Hashtable实现了ICollection和IEnumerable当它已经实现IDictionary继承这两个接口？

Answer 1

由于直接基类的Hashtable是System.Object它实现了无接口，接口重新实现不能与此有关。

由于 IDictionary不隐藏任何它从 IEnumerable继承部件（例如，它不声明 new方法 GetEnumerator()），得到为具有相同名称的部件不同的实现也可以不是原因。

既然“惯常”的原因都不适用，我认为Hashtable没有特别的原因。

编辑：

不知道这是连一个答案。

上面的陈述其实是错误的。非通用IDictionary类型确实隐藏它从它的基本接口（非通用）IEnuemrable之一继承的成员（超载）GetEnumerator()。但不知道这是相关的。请参阅Hashtablehere和here中的两个实现。

新编辑：

其实，如果你查看源代码（发现如here），你看到的只是：

public class Hashtable : IDictionary, ISerializable, IDeserializationCallback, ICloneable 

但作为一个线程写入an answer已链接到由Henrik在编译后的IL中发表了一个评论，所有的基本接口仍然被明确列出。因此，从编译程序集中的IL转换到伪C＃的反编译器无法区分这种差异。

---

最终加入：

我真的想拿出涉及接口重新实现的情况下，如果你也给了一个已经指定派生接口的基础接口会的问题，但我不认为有任何存在。这是我的尝试：

​​

但结果不是一个例子。即使只为Elephant指定IDerived，也会重新实现所有接口，包括IBase。只有在Elephant既不指定IDerived也不指定IBase时，才会重新执行压制。

所以默特的答案和相关的答案是正确的，我的观点有点偏离主题。我会离开这个帖子让其他人学习，即使它与提出的问题没有严格的相关性。

Answer 2

说完这些intefaces：

interface IFoo1 {...} 

interface IFoo2: IFoo1{...} 

有如下之间的编纂方面没有差别：

class MyClass: IFoo2{...} 

class MyClass: IFoo2, IFoo1{...} 

第二个声明使得它更清楚开发商所有接口MyClass的类实现。因此，查看文档并查看MyClass实现IFoo1接口更容易，而无需挖掘IFoo2接口。