问IDictionary vs哈希表-

EN

现在，使用Hashtable的理由很少。Dictionary<>在大多数方面都比它更好。如果不是这样，您通常可以找到另一个强类型的集合，它比这两个集合都更能满足您的需求。

• Type-safe.
• None解决了装箱和unboxing.
• Implements code.
• Performs的严重开销，在许多方面与.NET和第三方IDictionary<>的兼容性比Hashtable更好。请参阅链接：Link #2.

、Link #1

如果您想知道为什么要将属性类型化为IDictionary<>而不是Dictionary<>，这有几个原因。

• 通常被认为是尽可能多地使用接口而不是常规类型的最佳实践，特别是在framework.
• It中可以相当容易地更改接口的实现，但是很难在不引起依赖代码兼容性问题的情况下更改具体类的性质。
• 使用接口，您可以利用IDictionary<>代码更有可能消耗更通用的接口Dictionary<>而不是具体的类Dictionary<>。因此，使用IDictionary<>可能会让其他开发人员更好地与property.
• There进行交互。这些都是我突然想到的。--

嗯，是的，如果他们把扩展属性定义为返回哈希表，那么他们就会一直坚持这样做，除非他们想破坏所有使用扩展属性的代码。

返回接口的全部意义在于，方法如何实现并不重要，只要它一直这样做即可。

“唯一的原因是使属性多态”没有抓住要点，你应该有很少的理由不应该这样做。如果你可以返回一个接口，那么在大多数情况下，这是一个很好的设计。

因此，这里的大多数答案都是关于将Dictionary与Hashtable进行一般用途的比较，而不是他们为什么选择那个特定的实现。

在特定实现中，您是正确的，它使用object作为返回类型，因此字典的强类型优势不可用。

do它归结为新旧，ArrayList，哈希表等是较旧的技术，通常很大程度上是不受欢迎的，因为它们没有大量的功能(在其他答案中描述)。尽管在这种特殊情况下没有使用这些功能，但切换回旧技术并没有很大的好处，它为个人发展提供了一个更好的例子。

所以更多的是“这就是我们现在做的方式”的问题