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

  • 1
    I would like to know your own idea about this after 7 years?
    – NingW
    Commented Apr 1, 2019 at 7:51

4 Answers 4


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.

  • Thank you, your examples really helped clarify the differences between the two for me. If I understand you right, the observer pattern uses a subscribe/broadcast system of messages for communication, while the mediator is like some globally accessible entity which objects can query for information.
    – Rachel
    Commented Feb 14, 2012 at 14:41
  • @Rachel - I would describe the observer as you did. The mediator probably isn't global, but is known to all the objects in the set that would have been communicating with each other but now go through the mediator. Unless mediator is implemented as an observer, in which case it knows about all those objects (at least through their observable interface, maybe directly) but they don't know about it.
    – psr
    Commented Feb 14, 2012 at 17:42

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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.