2012-05-02 204 views
0

观察图案 -
假设观察到轨道的项目:观察者模式-受试者保持到由观察者

  • 出了10个项目的,观察者仅希望被订阅3.
  • 对象调用观察者的功能,让他知道有 是一些更新。

现在,是否有责任向观察者发送只有3件物品的更新?

主题可以简单地告诉观察者有更新 - 去取10个之中的任何一个吗?

哪个是正确的出路?有关系吗?

+0

你是什么意思的项目?你的'subject'有一些项目,当这些项目改变时通知'观察者'? –

+0

@lazyberezovsky物品意味着观察者想要订阅的东西。 –

回答

0

我宁愿去与关于不同事件的具体通知。通常用推模式。像Hey, I just earned some money. Here is actual amount I have earned。而不是Hey, something happened to me.。后者将所有逻辑移动到客户端(观察者)。如果您有多个客户端,客户端应验证已更改的内容,并验证逻辑将被复​​制。其实如果你没有其他观察者,你不需要这种模式:)

另外,具体的通知只允许订阅客户感兴趣的事件。所以,当其他事情发生时观察者不会感到困扰即当受试者观看电影时)。

0

现在,是否有责任向观察者发送关于只有3个项目的更新?

OR

主题可以简单地告诉观察员,有更新 - 去取无论你想出来的10?

哪个是正确的出路?有关系吗?

这里没有绝对的正确答案。

这些都是实现选择,而事实上是在观察执行部分Design Patterns提到:

1-6。避免观察者特定的更新协议:推和拉模型。观察者模式的实现通常会让主题广播关于变化的附加信息。主题将此信息作为参数传递给Update。信息量可能差别很大。

在我们称之为推模型的一个极端中,主体向观察者发送关于变化的详细信息,无论他们是否需要。另一个极端是拉模型;该主题只发送最少量的通知,观察人员此后明确要求详细信息。

拉动模式强调主体对观察者的无知,而推动模式则假设主体知道他们的观察者的需求。推式模型可能会使观察者的可重用性降低,因为Subject类对Observer类进行了假设,而这些假设可能并非总是如此。另一方面,拉模型可能效率低下,因为观察者类必须确定没有来自主题的帮助而改变了什么。

_7。明确指定感兴趣的修改。您可以通过扩展主题的注册界面来提高更新效率,以允许注册观察者仅用于特定感兴趣的事件。当发生这种事件时,主体只通知那些对该事件有兴趣的观察员。支持这种方法的一种方法是使用Subject对象的方面概念。为了注册对特定事件的兴趣,观察者使用

无效主题::附加(观察员*,方面&兴趣);

其中interest指定感兴趣的事件。在通知时,主题将更改的方面作为更新操作的参数提供给观察者。例如:

无效观察员::更新(主题*,看点&利息);

如果它更有意义在你的情况下使用推模式,使个体具有观察员的需求更多的知识,并用一个方面模型,使观察者可以注册在特定部分感兴趣主题的数据,去为它!

我通常喜欢使用拉模型并接受观察者有一点的主题(这是容易实现)的详细知识的,但你会建议在您的情况可能是罚款。

1

这是主题保留观察员列表谁对这个问题感兴趣,并通过调用它的更新方法通知这些观察员。 观察者看保持的科目,它感兴趣的列表。

在此基础上,当对象被更新,主题将调用更新(..)方法或类似这些观察员的东西名单。主题可以要么封装在一个对象的变化作为方法的参数,或者通过本课题的这个对象(观察者通过调用对象的方法本身获取感兴趣的数据)。