Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Mediator vs Observer what is the difference?

 
andy armstrong
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Everyone,
I am a little hung up on the difference between
these two patterns. Can anyone explain straight forward like what the difference is?
 
Rufus BugleWeed
Ranch Hand
Posts: 1551
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMHO
A lot of these patterns seem the same and things
have changed alot in the software world since 1995
when the GOF published their landmark work.
The mediator is like a central class that recieves
notifications from external sources. An external
source might be a text box or a slider. In the old days you might write your own slider. Being
a quick and dirty sleeze coder, you would weave
the code for it in with the rest of your application. But now Sun gives you the code for
all the controls. Their all already in seperate encapsulated and you glue them together with a mediator. If you are creating event sources then
it comes in handy.
Observer uncouples an event source from an event
listener. The event source just asks that any
interested parties register or unregister their
interest. When the event happens the source will
send notification.
One does not have to make any chage to the source
when a new listener is needed.
I think a mediator is a somewhat a complicated observer.
 
Alexander Yanuar Koentjara
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Observer is similar technology used in ActionListener. Bsically, Observer is the Listener and Observable is the GUI component. The event is the message. When a condition is changed in Observable object, the Observer object will get notified using the *Event* (may be just a simple message, eg: "xyz button is pressed!")
Mediator's goal is as a container of different components (perhaps with different tasks) and to handle/glue them according to flow/bussines logic.
Eg: Mediator have 2 components: a button "Disconnect" and a status bar. When user press "Disconnect" button, the status bar will show "Disconnected from server". Here mediator serves as container of the two components, as well as logic implementation handler. The mediator knows exactly that the button and status bar are exist (registered), and it knows that status bar should be updated when button is clicked.
There is no need a Mediator if the registered component is a few only. In above example, instead of using Mediator, you can simply change it with Observer: the button is the observable, and the status bar is observer. When button is clicked, the status bar get notified and update itself.
However, let's said: there are 10 buttons, 10 status bar, when 3 buttons are clicked 5 status bar will be changed, if 2 buttons are clicked, it will disable the rest of button, etc. In this case, observer only won't be enough. There should be a *mighty* object which should know every component and handle the updates... that is the Mediator.
[ June 03, 2002: Message edited by: Alexander Yanuar Koentjara ]
 
Sanjay Raghavan
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mediator provides loose coupling among colleagues. Eg. There are three colleagues. When the state of one colleague changes, the other two colleagues need to be informed of the change. Instead of all colleagues holding references to all others, they only talk to a mediator. The mediator informs the other colleagues of the change.
Often, the mediator uses the observer pattern if more than one colleague needs to be notified of the change.
In the observer pattern, the registered observers have to be notified when the observable object changes state. The observers may then query the object to synchronize their own states. The observers may use a mediator to accomplish this. Observers are useful for event listeners. Pub-Sub messaging in JMS would also be an example.
HTH.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic