内容观察者是观察者模式的实现吗？

Question

观察者模式由“四人帮”Design Patterns book 定义为“对象之间的一对多依赖关系，因此当一个对象更改状态时，它的所有依赖项都会收到通知并自动更新”。

他们还说观察者模式应该用于以下任何一种情况：

• 当一个抽象有两个方面时，一个依赖于 其他。将这些方面封装在单独的对象中可以让您独立地改变和重用它们。

• 当更改一个对象需要更改其他对象，而您不知道需要更改多少对象时。

• 当一个对象应该能够通知其他对象而不使 关于这些对象是谁的假设。换句话说，你不 希望这些对象紧密耦合。

在 Adam Stroud Android Database Best Practices book 上，它声明 “Cursor 类提供了将观察者模式暴露给数据源的方法。并且，通过使用这些方法，可以使用观察者模式而不是轮询数据库的变化，这可能是低效的”：

• Cursor.registerContentObserver()

• Cursor.unregisterContentObserver()

• Cursor.setNotificationUri()

同样，通过使用 ContentProvider，我们可以使用 ContentResolver 客户端对象来访问来自 Content Provider 的数据，然后注册一个 ContentObserver 来监听观察者注册的 URI 后面的数据变化。

所以，作为观察者模式中的 Subject 对象，ContentResolver 的方法在我看来几乎是一样的：

• ContentResolver 的 registerContentObserver() 是来自 Subject 的 Attach()

• ContentResolver 的 unregisterContentObserver() 是来自 Subject 的 Detach()

• ContentResolver 的notifyChange() 是来自Subject 的Notify()

那么，我的问题是，如果 ContentProvider 的三个组件（ContentProvider、ContentResolver 和 ContentObserver）本身就是观察者模式的实现？

即使我找到了一些证据表明它可能是观察者模式的实现，我也想要一个具体的答案来解释它是否真的是观察者模式的实现。

Answer 1

是的，这些组件提供了观察者模式的实现。

“四人帮”一书中描述的设计模式中最重要的部分是它们所体现的概念。方法、类等的命名等细节通常因实现而异。 Attach()/Detach()、register()/unregister()、watch()/unwatch() 等。这样的选择最终相对无关紧要。关键问题是：实现是否与您引用的描述相匹配，即它是否是“对象之间的一对多依赖关系，以便当一个对象更改状态时，它的所有依赖项都会收到通知并自动更新”。我建议我们在这里显然有这种情况。此外，拥有一个名为 ContentObserver 的类也很好地表明我们确实在处理某个版本的观察者模式。

当然，这里还有一层复杂性，因为 Android API 的要求通过将 Subject 分为 ContentProvider 和 ContentResolver 类来复杂化它的结构。在这种情况下，ContentProvider 确实是Subject，但所有交互都需要通过ContentResolver 处理。然而，这种并发症并没有改变行为的基本性质；它仍然是观察者模式。