Midiator vs Observer or Publish Subscriber Pattern vs Event Aggregator Pattern

There is quite overlap in the Mediator and Observer/Publish-Subscriber pattern. Mediator pattern provide a way to decouple the Subject and Observers and move the communication logic to the middle component. This makes the Subjects and Observers decouple and reusable and allow them to grow independently without bothering each other. Otherwise, components will be coupled to each other and they will be less reusable and maintenance can be problematic.

Event based GUI programming used both design patterns (Mediator and Observer/Publish-Subscriber pattern). Usually GUI form is a mediator and the different components on it are the Subjects and Observers. One component can be both Subject and Observer at the same time. It can send events and it can subscribe event. In case of GUI, the Form component subscribes the different events of the components on the form and different event handlers on the form do the communication and state changing logic in its events. All the communication, co-ordination, state changing, data binding, data fetch, data validation, event subscription is done on the form or mediator.

The same Mediator and Observer/Publish-Subscriber pattern can be implemented on the complex business logic object. We can simulate this on the complex business logic objects in the memory that do the different things in the back ground like logging, data base persistence, emails, service invocation, database backup, data uploading, data downloading and many other those have less to do with the GUI.

Event aggregator design pattern is a specialized case of Observer + Mediator design pattern. In this pattern, the Mediator also handles the event-wiring and registration and un-registration logic of the events. It further decouples the Subjects and Observers and really makes them reusable and maintainable.