October 02, 2012

Notification pattern vs. Observer

In a previous article I wrote about the Notification pattern and it's implementation in Javascript, the language I've been using the last couple of months to implement an application allowing users to design greeting cards online using a web browser.

From a technical point of view the application would best have been based on SVG or the HTML5 CANVAS element, but that's a different story altogether. The application uses HTML and CSS and every trick -even those not in the books- to perform it's job. These tricks mostly relate to CSS-magic and a lot of Javascript to make IE perform tasks that do not require programming for other browsers. Sigh!

But enough on that, let's get back to the main subject of this blogpost, comparing the Notification-pattern to the Observer pattern.

Observer pattern

Observer is a design pattern where observers can register with a subject that implements the observable interface. The interface defines methods for registering and unregistering as observer. The subject is responsible for keeping track of observers.

The goal of this pattern to allow observers to be notified of a state-change in the subject, allowing the observers to take appropriate action and keep in sync with the state of the subject. This sounds like an ideal solution applicable in many situations. And in some situations it indeed is. But there are major drawbacks to the pattern.

Object life-cycle

During application execution, objects come and go. In interactive applications mostly because of user interaction. Let's consider a simple drawing application with a canvas like area. The application allows the user to create objects (Images, text etc.) and manipulate these. The application has a tools palette whose contents depends on the currently selected object. The contents of the tools palette is determined by the type of object currently selected and the state of the object.

Such a situation implies the tools palette (or more likely: it's controller) needs to be informed when new objects are instantiated. It needs to have access to each and every object capable of instantiating objects relevant to the tools palette. Next to that it needs to be registered as observer with all these objects.

This is the major drawback of the observer pattern. A shortcoming that can be remedied by introducing a third party: the Notifier.

Notification pattern

The notification pattern introduces a third party that decouples observer and observable. This decoupling has several implications. Observers need not register with each and every observable. They register with the notifier for the receipt of given notifications. Observers also aren't bothered anymore with the complications caused by instantiation of new objects. A final benefit is that observables are relieved of implementing the interface keeping track of all observers and distributing messages to these observers. In the notification pattern, these tasks are performed by the notifier.

Considering all these benefits, situations where use of the observer pattern is favorable over the notification pattern will be rare.

In the near future I will post a live example showing a use-case of the notification pattern.

Update- The example and extensive documentation is available: Notifier design pattern.

No comments:

Post a Comment