Dec 8, 2011

Observer design pattern for publish/Subscribe model

The design patterns are very popular with the interviewers and Java/J2EE Job Interview Companion covers GoF design patterns, JEE design patterns, and EJB design patterns. This blog entry covers the observer design pattern.

Q. What is an observer design pattern?A. The Observer pattern is a behavioral design pattern that allows an object (an Observer) to watch another object (a Subject). The subject and observer to have a publish/subscribe relationship. Observers can register to receive events from the Subject.

Some of the practical uses of observer pattern are:

When a change to one object requires changing of others, and you don't know how many objects need to be changed.

When an object should be able to notify other objects without making assumptions about who these objects are and not tightly coupling them.

When a report is received or an event occurs, a message needs to be sent to the subscribed handlers.

Examples:

Programming Swing based GUI applications where the listeners register them with events like button click, property change, etc.

Programming a stock market application to know when the price of a stock changes.

Programming a order placement or trading application to know the status changes like pending, filled, shipped, rejected, etc.

So, whenever you want to have the state change or other information, instead of polling every few second, register the observers with a subject.

Q. Can you list some Java interfaces that use the observer design pattern?A.

The Java Message Service (JMS) models the observer pattern, with its guaranteed delivery, non-local distribution, and persistence, to name a few of its benefits. The JMS publish-subscribe messaging model allows any number of subscribers to listen to topics of interest. When a message for the published topic is produced, all the associated subscribers are notified.

The Java Foundation Classes (JFC) like JList, JTree and the JTable components manipulate data through their respective data models. The components act as observers of their data models.

In the java.util package, we have the Observer interface and the Observable class.

In an MVC (Model-View-Controller) architecture, the view gets its own data from the model or in some cases the controller may issue a general instruction to the view to render itself. In others, the view acts as an observer and is automatically notified by the model of changes in state that require a screen update.

Q. What are the pros and cons of an Observer design pattern?A.

PROS:

Loose coupling between Subject and Observer: The subject knows only a list of observers, that implement the Observer interface, it does no know the concrete implementation of the Observer.

Broadcast communication: An event notification is broadcast to observers irrespective of the number of Observers

CONS:

If not used carefully the observer pattern can add unnecessary complexity.

The order of Observer notifications is undependable. Simply registering the observers in a particular order will not enforce their order of notification. You don't necessarily know if the first registered listener is notified first or last. If you need to have cascading notifications, where object X must be notified first, followed by object Y, you must introduce an intermediary object to enforce the ordering.

The possibility of a memory leak. A reference to the Observer is maintained by the Subject. Until the Subject releases the reference, the Observer cannot be removed by the garbage collector.