将主题映射到他们的观察者 - 观察者模式 GoF 书答案

【问题标题】：Mapping subjects to their observers - Observer pattern GoF book将主题映射到他们的观察者 - 观察者模式 GoF 书
【发布时间】：2019-02-12 05:31:54
【问题描述】：

在GoF设计模式一书中，说到观察者模式的实现部分，是这样说的：

将主体映射到它们的观察者 主体跟踪它应该跟踪的观察者的最简单方法 notify 是在主题中明确存储对它们的引用。然而，这样的存储可能过于昂贵当主体多，观察者少时。一种解决方案是通过使用关联查找（例如，哈希表）以维护主题到观察者的映射。因此一个没有观察者不会产生存储开销。另一方面，这种方法增加了访问成本观察者。

我看不到使用哈希表如何提高存储容量。在 Java 中，对于每个主题，我们都可以有一个观察者列表 List<Observer>。如果没有附加到此主题的观察者，则列表引用将为空。如果我们使用哈希表，Map<Subject, List<Observer>，我们仍然有列表，但我们也有一个对主题的引用，所以这种方式有点更多内存效率低下。我不知道它是否相关，但Gof书中用于实现的语言是Smalltalk和C++。

【问题讨论】：

我同意它的神秘。请记住 GoF 是在 1994 年编写的，而 24 年对于计算机硬件/软件而言是一段很长的时间。那时PC内存也以MB而不是GB来衡量，所以小额节省可能很重要。您需要访问当时的 C++ 编译器和库，以进行空间比较。使用当今的 CPU 速度和内存，以及跨主要语言，para 可以安全地忽略 .. 除了大型网站速度优化将是一个因素。

标签： design-patterns observer-pattern observers

【解决方案1】：

这句话的意思似乎是，如果受试者负责存储自己的观察者，在大多数受试者在给定时间未被观察到的情况下，每个受试者都承担存储空列表的成本（想象数百万受试者)。

另一方面，如果将对象到观察者的映射集中到单个 Map 中，则只有（少数）被观察对象有任何内存占用。正确指出，使用集中映射，每个观察对象的内存成本更高，因为需要存储对对象的引用，这就是为什么这样的设计只有在“当有很多对象和少数观察者时”才有意义.

注意一个更现代的优化代码以避免空集合的示例：Why overload the varargs method of() in Java Stream interface?

【讨论】：

谢谢，我认为这就是它背后的逻辑。我只想补充一点，开销不是一个空列表对象，正如我最初在我的问题中建议的那样，而是一个列表引用，一个列表对象的创建可能会被阻止，直到第一个观察者附加到主题。