问题
I always found the Observer Pattern almost similar to the usual event-driven approach. Actually, I have almost believed that they are actually just different names referring to the same thing. They both use similar concepts to have something as a listener and even in the implementation, they are almost the same thing, that's to have a callback method/function to carry out an action. This is at least in Java.
In other languages say Actionscript/Flex, the events are more user-friendly and may look like it does more than just the observer pattern defines. But still, the concepts sound the same.
But is this really true? Is the Observer Pattern the same thing as the usual event-driven programming style?
回答1:
The Observer Pattern is a very special instance. Event-Driven can mean anything. In most Observer Pattern implementations the Observer is an object watching the observee. When the observee is changed, a method of the observer is called. Strictly speaking this is not an "Event". That means: various different actions on the observee, usually lead to the call of different methods in the observer. The semantics "what" got changed is in the method. In Event Driven Systems, you basically have one consuming object/method and the message what was changed or what happend is in the Event. That can be anything and is not limitd to the idea of observing something! That means: in an Event Driven System you get new semantics by adding new Event types. In an Observer Pattern you usually add semantics by adding a method to the Observer class. HOWEVER: no one is preventing you to implement an Observer as a special listern to ChangeEvents.
回答2:
When there is a state change at the Publisher or Subject,
Event Driven Architecture (is a message-driven architecture), responsible to deliver message to Subscriber, asynchronously.
Observer Pattern (is a software design pattern), responsible to command Subscriber to do something, synchronously.
回答3:
Event-driven programming is a term to define a paradigm. whereas Observable pattern is a design solution to make an application event-driven.
Cheers!
回答4:
The diffrence No.1 may be, that Event-Systems always have an eventdispatchthread which decouples observables from its observers so events may not reach the observers immediatly. While real observables call observer methods directly, event driven observables drop their events into an eventqueue. Then the EDT deliveres those events to registered listeners.
回答5:
Synthesizing from multiple answers in this question, this hackernoon article, and my own experience, the key difference between the Observer Pattern and Event-Driven (Pub-Sub, say) Architecture is, in my mind, this:
In the Observer Pattern, the Observed maintains references to its Observers.
Whereas in Pub-Sub, the Broadcaster has no idea who its Listener(s) are. (Or even if anyone is there to listen.) The Listener may expect some data from the Broadcaster, but has no idea exactly where the event comes from. Maybe it comes from multiple classes or remote systems. Maybe not. It doesn't matter to either the Broadcaster or Listener.
Now, that's not to say these things are very different. Also, there are implementations that behave like either or both.
For example, the wisper rubygem allows you to act like either an Observer pattern or a Pub-Sub pattern depending on your need. You can even use both together if you like.
回答6:
I've searched a bit for this same question. For this thread, I find point from Angel O'Sphere on "What semantics" and point from Spacerat on "Dispatcher" do helps.
That two points are my understanding that distinguish Even-Driver from Observer Pattern. At least from canonical explanation, "Observer Pattern" usually represents an immediate broadcasting once the "Subject" has changed and the "Dispatching" is implemented by calling the interface provided by subscriber or listener. While for Event-Driven, there is always another layer between "Subject and "Observer". Either called "Dispatcher" or using "Event Queue". This provides the "delayed" handling to reduce CPU usage and also provides certain capability on calling different interfaces depends on different event type.
回答7:
The basic difference in both is coupling and synchronous behaviour. If we stick with observer pattern, we say there is only one source of signal and it would be synchronous, while on other hand with events, we decouple both parties to work independently and the same time entertain the possibility of having more than one source of events in future without any code changes. Events help us to embrace async as design. All Reactive programming library provide very good support for event driven design.
回答8:
I try it very simple, because that helped me once too.
Just think as a Observer and Observable. Instead that the observable marks a setChanged and the observer requests from the observable what has changed, the observable instead broadcasts an object (Event Carried State) with all relevant information about the change to the observers. So there is actually one more instance between the Observer and the Observable.
http://www.grahambrooks.com/event-driven-architecture/patterns/stateful-event-pattern/
回答9:
Yes, they are the mainly same.
Events are something like a "built-in" observer pattern template for some languages.
Thus, you wouldn't really implement the observer pattern in a language which supports events as they already provide what you are looking for.
On the other hand, you can write event-driven in languages which lack events by using the observer pattern.
回答10:
From Wikipedia :
The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.
It is mainly used to implement distributed event handling systems, in "event driven" software. Most modern languages such as Java and C# have built in "event" constructs which implement the observer pattern components, for easy programming and short code.
The observer pattern is a little more abstract and theoretical. Events are one (commonly built-in) implementation, however as noted in Angel's answer Events tend to be able to be used in a few other situations apart from what is strictly defined in the observer pattern.
回答11:
Event-driven is a software paradigm or style of writing code where objects communicate using events. Some languages like C# have native support for events. You can have an object raise an event to which another object listens to. The Observer Pattern is another way to achieve the same result.
来源：https://stackoverflow.com/questions/6439512/difference-between-observer-pattern-and-event-driven-approach