Car*_*ven 61 events design-patterns observer-pattern
我总是发现观察者模式几乎与通常的事件驱动方法类似.实际上,我几乎相信他们实际上只是指同一件事的不同名称.他们都使用类似的概念来作为一个监听器,甚至在实现中,它们几乎是相同的东西,那就是有一个回调方法/函数来执行一个动作.这至少在Java中.
在其他语言中说Actionscript/Flex,事件更加用户友好,并且可能看起来不仅仅是观察者模式定义.但是,这些概念听起来仍然相同.
但这是真的吗？观察者模式是否与通常的事件驱动编程风格相同？
Ang*_*ere 36
观察者模式是一个非常特殊的实例.事件驱动可能意味着什么.在大多数观察者模式实现中,观察者是观察观察者的对象.当观察者改变时,调用观察者的方法.严格来说,这不是一个"事件".这意味着:对观察者的各种不同行为,通常会导致观察者对不同方法的调用.语法"什么"改变了在方法中.在事件驱动系统中,您基本上有一个消费对象/方法以及事件中已更改或发生的消息.这可以是任何东西,并不限于观察某事的想法!这意味着:在事件驱动系统中,您可以通过添加新的事件类型来获得新的语义.在Observer模式中,您通常通过向Observer类添加方法来添加语义.但是:没有人阻止你将Observer实现为ChangeEvents的特殊池.
Zei*_*ist 26
当发布者或主题发生状态更改时,
事件驱动架构(是一种消息驱动架构),负责以异步方式向订阅服务器传递消息.
Observer Pattern(是一种软件设计模式),负责命令 Subscriber同步执行某些操作.
小智 10
差异No.1可能是,Event-Systems总是有一个eventdispatchthread,它将观察者与其观察者分离,因此事件可能无法立即到达观察者.虽然real observables直接调用观察者方法,但事件驱动的observables将其事件放入事件队列中.然后,EDT将这些事件传递给已注册的听众.
the*_*uth 10
综合这个问题的多个答案、这篇hacknoon 文章和我自己的经验，观察者模式和事件驱动（Pub-Sub，比如说）架构之间的主要区别在我看来是这样的：
在Observer模式中，OBSERV版保持其OBSERV引用ERS。
而在 Pub-Sub 中，Broadcaster 不知道它的 Listener(s) 是谁。（或者即使有人在那里收听。）侦听器可能会期望来自广播者的一些数据，但不知道事件的确切来源。也许它来自多个类或远程系统。也许不吧。无论是广播者还是听众都无关紧要。
现在，这并不是说这些东西非常不同。此外，有些实现的行为类似于其中之一或两者。
例如，wisper rubygem允许您根据需要充当观察者模式或发布订阅模式。如果您愿意，您甚至可以同时使用两者。
小智 5
观察者模式的一大优点是安全。当被观察者对象内发生代码更改时，所有观察者都必须实现新的更改。如果我们使用事件来代替，事件侦听器将不会对新事件的实现做出反应。换句话说，观察者规定事件必须由观察者处理。
在我的一个项目中，我遇到了一种情况，其中一个被观察者对象被破坏，需要在这样做之前通知观察者。我唯一要做的就是添加通知作为所有观察者的要求，并在观察者被摧毁之前触发事件。这里的美妙之处在于，只有所有观察者都为新创建的事件实现了处理程序，代码才会编译，因此您不太可能忘记更改其中的一些观察者。就我而言，我有相当数量的可能的观察者，很高兴知道我可以进行更改而不会产生一些或更多隐藏的错误。
这些品质使得观察者模式不像简单地抛出一个事件并让观察者自己决定那样灵活。但是，在使用事件时，请小心隐藏在拐角处的意大利面条怪物，并且只有在截止日期临近时才会出现。可能很多人都和我一样，不止一次遇到过这个丑陋的野兽。
换句话说，尽可能务实，并仍然使用正确的工具来完成工作。这意味着当您需要灵活性时使用事件，而当您需要控制时使用观察者。