无法理解观察者模式,解耦在哪里

时间:2013-07-02 10:52:02

标签: design-patterns observer-pattern

我正在阅读第一个设计模式,他们试图解释观察者模式。 如果我理解正确,这种模式的目的是将观察对象与数据本身分离。

它是通过从IObserver继承并使用“Update”方法完成的,然后注册到某个接口,该接口应该在更改内容时调用我的更新。

但是在一些事情发生变化之后,我仍然需要反对自己来检查究竟发生了什么变化,那么去耦在哪里呢?

在我在书中的示例中,他们制作了几个不同的天气小部件,这些小部件依赖于来自传感器群的数据。 他们试图将小部件与传感器分离,但是你可以看到他们有一个从每个小部件直接指向传感器数据的指针(它写在页面底部),所以实际上根本没有解耦

我错过了什么吗?

enter image description here

3 个答案:

答案 0 :(得分:3)

观察者模式将观察者与观察者分离。它不会将观察者与观察产生的数据分离。

因此,在本次讨论的情况下,天气数据的多种类型的显示器(观察者)已经与监测天气数据的仪器(主体)分离。

为了验证这种解耦是否真实,你需要问问题"如果我还要再添加一个观察者,我需要更改多少个类来添加新的观察者?" - 在这种情况下,答案是零,因为你只是添加一个新的观察者类,它将自己注册主题。并且"主题"中不会出现单行代码更改。或其他观察员"。

观察者设计模式在某种程度上可以帮助您实现开放闭合原则(OCP)。按照这个原则,一个班级应该是#34;打开扩展"但是"关闭以进行修改"。

希望这澄清!

答案 1 :(得分:1)

在本书的示例中,Observer对象实际上与Subject对象耦合。

耦合起源于观察者必须知道存在于主题中的信息。

但是,这种模式可以用不同的方式实现,因此可以避免这种耦合。最简单的方法是在调用通知观察者某些内容发生变化的方法时,将信息作为参数传递。 (这称为“推送”数据)

根据您的示例,该方法的签名可以是:

  

更新(int温度,int湿度,int压力)

答案 2 :(得分:0)

这种设计模式通常用于注册事件,该事件的寄存器独立于事件本身,但必须与给定接口相邻,当事件发生时,每次注册的观察者的实际实现都是通过致电object.update()来通知活动。

可能你可以看到解耦是你可以给你的库做和处理事件,你的库的用户可以注册它们,你会调用他们的代码,可能不知道那些代码是什么

现在更多模糊