When would you use the mediator design pattern

As the title states when would you recommend the use of the mediator design pattern and where do you see it used incorrectly?

From stackoverflow

• I have used it to deal with swing apps.

  When I'm building a GUI I don't like each control know each other because that would require subclassing.

  Instead I have a Main object whose contains the listener and the widgets and let it mediate between the different controls, buttons, textfields etc.

• Use a mediator when the complexity of object communication begins to hinder object reusability. This type of complexity often appears in view instances, though it could really be anywhere.

  Misuse of a mediator can result in crippling the interfaces of the mediator's colleague classes.

  It seems a little funny to talk about misusing a pattern. If your implementation follows the pattern, then you've used the pattern. Otherwise, you haven't. In other words, if your mediator is doing something else, then it probably isn't a mediator. Patterns are defined by what they do, what they in fact are. The names of things are simply labels.

  The real question to ask yourself is whether your implementation of a pattern fulfills the pattern's promises for your design. The mediator pattern aims to encapsulate complex inter-object communication when it is becoming unmanageable. If it hasn't accomplished this, or hasn't done it very well, you could say that a mediator is being misused. At some point, it becomes a value judgement.

  OscarRyz : 1+ for the answer

  hhafez : could you give more details on the misuse? Thanks

  keparo : (added a note above)

• The mediator is also basically what an event-pump is. A very common pattern in GUI's and Games.

  Also I've used mediator before to communicate among very dispar systems, and legacy frameworks.