我正在阅读 head first 设计模式，他们试图解释观察者模式。 如果我理解正确，这种模式的目的是将观察对象与数据本身分离。
这是通过从 IObserver 继承并具有“更新”方法来完成的，然后注册到某个接口，当某些内容发生更改时应该调用我的更新。
但是在某些事情发生变化之后，我仍然需要反对自己来检查到底发生了什么变化，那么解耦在哪里？
在我书中的示例中，他们制作了几个不同的天气小部件，这些小部件依赖于来自一堆传感器的数据。 他们试图将小部件与传感器分离，但正如您所见，它们有一个从每个小部件直接指向传感器数据的直接指针（它写在页面底部），所以实际上根本没有解耦.
我错过了什么吗？
【问题讨论】：
标签： design-patterns observer-pattern
观察者模式将观察者与被观察者分离。它不会将观察者与观察生成的数据解耦。
因此，在本次讨论中，天气数据的多种显示（观察者）已与监测天气数据的仪器（主题）分离。
为了验证这种解耦是否真实，您需要问一个问题“如果我必须再添加一个观察者，我需要更改多少个类才能添加新的观察者？” - 在这种情况下答案为零，因为您只是添加了一个新的观察者类，它将向主题注册自己。并且“主题”或“观察者”的其余部分都不会发生单行代码更改。
在某种程度上，观察者设计模式可以帮助您实现开闭原则 (OCP)。按照这个原则，一个类应该是“开放扩展”但“关闭修改”。
希望这可以澄清！
【讨论】：
在您书中的示例中，Observer 对象与 Subject 对象有效耦合。
耦合是因为观察者必须知道存储在主题中的信息。
但是，这种模式可以以不同的方式实现，因此您可以避免这种耦合。最简单的方法是在您调用通知观察者某些已更改的方法时将信息作为参数传递。 （这称为“推送”数据）
根据您的示例，方法的签名可能是：
更新（温度、湿度、压力）
【讨论】：
这种设计模式通常用于注册事件，为该事件注册的内容独立于事件本身，但必须遵守给定的接口，当事件发生时，为该事件注册的观察者的每个实际实现事件通过调用object.update()得到通知。
您可能会看到，解耦是指您可以为您的库提供执行和处理事件，并且您的库的用户可以注册它们，您将调用他们的代码，可能不知道该代码的作用.
现在是不是更晦涩了？
【讨论】：