Preparing to Implement an Observer

Implementation details for the Observer pattern seek to constrain the environment and ensure that clients have the latest data:

The Observer pattern typically applies to coarse change events: Examples of these are "a change occurred in this object" or "the state of this business process changed." Extensions to the Observer pattern often apply to the attribute level of an Observable object, though the base pattern does not cover this level of granularity. For example, Java extends the Observer pattern within the language with the JavaBean Property Change patterns.

When notifying a client of a change through the update method, include a reference to the object that changed: This allows clients to use the same Observer implementation for multiple Observable objects.

Include data from the changed object in the update method that you think the Observer will use: Without the data, the Observer is highly likely to call back to your Web Service for more information about changes.

You need to register an Observer with every object that has interesting state changes: The implications of this are profound if you consider a massive application. Each component may be registered with dozens or hundreds of components , with each having its own event delivery mechanism. Further, the burden on the client for maintaining these relationships can be daunting. Consider the case where an application goes down; upon restart, the observers must be registered again with every interesting target.

The Observer pattern only works with target objects that already exist : It is difficult to target an object for changes when the object does not exist. There are interesting webs of objects to address this issue. As an application programmer, you may add an Observer interface to a business object collection and to the business objects within the collection. With this mechanism, clients can observe both object creation and deletion operations as well as observe changes to individual business objects.