2014-02-19 149 views
0

我已经看到了使用列表存储所有接收者的Publisher订阅模式的几个实现。散列表发布者订阅模式

但他们都没有使用散列表。

因此,我想知道为什么?为什么我们不应该使用散列表来达到这个目的,是否有任何理由?

感谢

回答

1

Hashtable优化查找。在这里,你可以找到典型应用案例:http://www.dotnetperls.com/hashtable

在你的任务,你只需要遍历所有用户,因此可以用它实现IEnumerable<T>接口的集合,但没有必要对Hashtable

+0

虽然,如果你的列表的用户会变得很大,您可以使用通用字典按类型或其他常见因素对用户进行分组,以优化查找相关用户的过程。 –

+0

对于取消订阅而言,您确实需要查找,因此每个发布服务器订阅者模式在我看来都应该使用散列表 – taktak004

+0

@DavidOsborne理论上是的。但我想不出真正需要pub/sub消息过滤的真实例子。它总是必须分成不同的部分或重新分配我认为 – astef