Can someone provide me with a canonical answer on the differences between an Observer and a Mediator, and a summary of when you should use one pattern over the other?
I am unsure of what kind of situation would require an Observer and what kind would require a Mediator
In the original book that coined the terms Observer and Mediator, Design Patterns, Elements of Reusable Object-Oriented Software it says that the Mediator pattern can be implemented by using the observer pattern. However it can also be implemented by having Colleagues (roughly equivalent to the Subjects of the Observer pattern) have a reference to either a Mediator class or a Mediator interface.
There are many cases when you would want to use the observer pattern, they key is that on object should not know what other objects are observing it's state.
Mediator is a little more specific, it avoids having classes communicate directly but instead through a mediator. This helps the Single Responsibility principle by allowing communication to be offloaded to a class that just handles that.
A classic Mediator example is in a GUI, where the naive approach might lead to code on a button click event saying "if the Foo panel is disabled and Bar panel has a label saying "Please enter date" then don't call the server, otherwise go ahead", where with the Mediator pattern it could say "I'm just a button and have no earthly business knowing about the Foo panel and the label on the Bar panel, so I'll just ask my mediator if calling the server is O.K. right now."
Or, if it is implemented using the observer pattern the button would say "Hey, observers (which would include the mediator), my state changed (someone clicked me). Do something about it if you care". In my example that probably makes less sense, but sometimes it would, and the difference between Observer and Mediator would be more one of intent than a difference in the code itself.
The Observer pattern works well when no coordination between the observers is necessary and the observes relationship goes one way.
For example, let objects B and C observe object A. When object A fires event X, then object B should execute method Y() and object C should execute method Z(). If methods B.Y() and C.Z() are totally independent and require no coordination, then go ahead and use the observer pattern.
On the other hand, if B.Y() must be executed before C.Z() then you will want to use the Mediator pattern where the mediator encapsulates this coordination. In this scenario, mediator M would observe object A and would have references to objects B and C. When A fires event X, M will handle the event and call B.Y() and C.Z() in the prescribed order.
Also, if objects A, B and C need to observe each other then using a mediator as an intermediary will go a long way to decouple these objects and avoid spaghetti code.
The Observer pattern is used when an action taken on one class (the observed class) needs to produce a reaction in another class (the observing class) but it is undesirable for the observed class to be coupled to the observing class. This is a very common pattern. The SAX XML parser may be a good example. To use the SAX parser, a client implements the ContentHandler interface to "observe" the parser operation. As the parser encounters elements of the XML document, it calls methods of ContentHandler. The parser is able to invoke client code, but the parser is not coupled to the client code.
The Mediator pattern is an encapsulation of a pattern of usage of a set of objects. Client code is only coupled to the mediator, instead of being coupled to multiple other classes. It's similar to aggregation, except the lifetime of the encapsulated objects is independent of the lifetime of the mediator.
In simple terms (that I use to remember it):
Observer: Use when one objects wants to be informed of state changes in another (strictly speaking, using events is Observer)
In order to understand mediator, I find it easier when you consider Facade first: Facade aggregates the functionality of separate classes (entire subsystems sometimes) and provides that functionality in a single interface.
Mediator: Same as Facade, except that it combines the functionality of all of the aggregate classes to produce new functionality. (Good explanation here)
