HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

The Observer Design Pattern is among the most useful for object-oriented software design. The JDK itself makes heavy use of a variant of this pattern in the 1.1 AWT event delegation model. The JDK also provides a reusable embodiment of the pattern in the form of the java.util.Observer interface and the java.util.Observable class. If you've done much serious Java programming you've more than likely had occasion to use these classes.

The idea of the pattern is to model a one-to-many dependency without tightly coupling the observed object with its many observers. When the observed object changes in some interesting way it can automatically notify all of its observers without knowing them directly. For more on this pattern, see Qusay Mahmoud's article, "Implementing Design Patterns in Java" (JDJ, Vol. 2, Iss. 5), or the Design Patterns book.

Unfortunately, a number of weaknesses have been identified in the JDK's Observer/Observable classes. Peter Coad and Mark Mayfield discuss some of these weaknesses in their excellent book, Java Design. These weaknesses significantly limit the reusability and power of the classes, which is a shame since powerful reusability is a big part of what object-oriented design is all about.

Most of the weaknesses are due to the fact that java.util.Observable is a class rather than an interface; or rather, that it is a class without a corresponding interface. This implies that the only way to reuse Observable is to subclass it. You can't take an existing class and tack on the role of Observable by having it implement an Observable interface because there is no Observable interface.

What if you have a class that is already in a class hierarchy and also needs to play the role of an Observable? Since Java doesn't support multiple inheritance, you're out of luck. That class cannot extend from Observable because it is already extending from some other class.

It also means that you are stuck with the one and only implementation of Observable in java.util.Observable. For a variety of reasons, you may want to use an alternate implementation - e.g., to do the notification in a separate thread or in a particular order. You may even want to vary the implementation of Observable at runtime. There is no Observable interface for your alternate implementations to implement. You cannot reuse Observable by composition so you cannot vary the composed Observable implementation at runtime.

The designers of the Observable class broke two general principles of object-oriented design with Java. The first principle is to design with interfaces rather than classes. Whenever possible, avoid committing yourself to a particular implementation of an interface. The second principle is to favor reuse by composition over reuse by inheritance unless a class hierarchy is clearly indicated. By omitting an Observable interface and making some of its methods protected, the designers made it impossible to reuse Observable by composition.

A minor weakness in Observable is the necessity to call setChanged() before notifySubscribers(). The intention there seems to be to eliminate needless notifications in cases where there is no interesting change to the Observable. There may be situations in which this two-stage notification is appropriate, but it isn't the simplest case and programmers shouldn't be forced to use this implementation in all situations. Also, setChanged() is protected, further reinforcing the necessity to reuse the class only by inheritance.

Now let's look at the Observer interface. The weakness here is its tight coupling with the Observable class. The first parameter to the update() method is unnecessarily typed as an Observable. If it were typed more generally as a simple Object, the Observer interface would be more reusable. It then could be used with any Observable implementation or even in any situation, completely unrelated to Observer/Observable, which called for a void method with two Object parameters.

Despite all these weaknesses, I was initially reluctant to ignore the JDK classes in favor of the homegrown replacements suggested by Coad and Mayfield. After all, the JDK classes are already locally available to every VM and they do serve their purpose nicely for the majority of cases. On the other hand, designing for maximal reuse is crucial to the success of any object-oriented design. A little forethought early in the game can lead to great savings down the road. Luckily, when I started a new project some months ago, I decided to take the plunge and start using the improved classes.

More recently I began designing a number of distributed three-tier Java apps using Remote Method Invocation (RMI). It turns out that the Observer pattern has great application to remote applications. A remote object that lives on the server often needs to be observed by multiple objects living on multiple clients. When the remote object changes, all clients need to find out in order to, for example, update the user's view.

The JDK's Observer/Observable classes are of no use here. They do not extend from java.rmi.Remote and their method signatures do not allow for the possible throwing of RemoteException. Both of these are required of any Remote interface for RMI. So the JDK's Observable/Observer classes can never be implemented as an RMI remote interface of a RemoteObject.

The solution that I've seen in articles and books is to write a separate set of classes for Remote Observable/Observer. This always seemed wrong to me. Why should I have to write, support and use two disjoint sets of classes to do basically the same thing albeit in different situations? What if I have a class that needs to notify both local and remote Observers? You mean it has to implement both versions of Observable?!

Having already severed my dependence on the JDK's Observable classes, I was able to painlessly enhance my classes to support Remote Method Invocation. The same classes can now be used for local Observers as well as remote Observers or even for a mixture of remote and local Observers.

The interfaces are shown in Listing 1. In order to avoid confusion with the JDK classes, I use the synonymous terminology of Publisher/Subscriber rather than Observable/Observer.

Notice that the Publisher and Subscriber interfaces extend from java.rmi.Remote and all their methods may throw RemoteException. This is so that these interfaces may be implemented by remote classes for use with RMI. These additions do not preclude these classes from being used in a strictly local situation without RMI. In fact, the same Publisher could be used to publish to a mixture of local and remote Subscribers.

A simple basic implementation of Publisher is presented in Listing 2. This Publisher can be used for both local and remote Subscribers.

The notifySubscribers() method deserves some elaboration. The call to the Subscribers' update() method is in a try/catch clause to deal with possibly thrown RemoteExceptions. Two particular RemoteExceptions, ConnectException and NoSuchObjectException, are considered serious enough to consider the Subscriber to be dead. Subscribers that are considered dead are removed from the list of Subscribers for this Publisher. Other RemoteExceptions may be indications of transient failures that could correct themselves. This is the type of fuzzy logic you need to apply in networked situations where errors are unpredictable and non-deterministic.

The dead Subscribers are not removed from the list of Subscribers until after the list is enumerated. At first glance you might ask, why not remove the dead Observers right away, within the catch clauses? This is because of a quirk in java.util.Vector that makes it unsafe to manipulate a Vector while it is being enumerated. This quirk (bug?) is a discussion for another time, but a few words about the workaround I chose are warranted here.

As I discover Subscribers that are to be considered dead, I accumulate them in a Vector. Only after enumeration of all Subscribers do I go through the Vector of dead Subscribers and actually remove them. Another workaround that I could have used is to clone the Vector of Subscribers before enumerating it. Then I could operate on the original Vector while enumerating the clone. I chose the workaround I did because it has little overhead for the more usual case when no RemoteException is thrown. Even the deadSubs Vector is not allocated until and unless it is needed. This technique is known as lazy instantiation.

The preferred way to reuse BasicPublisher is by composition. Any class that needs to play the role of a Publisher should implement the Publisher interface and include a reference to an instance of BasicPublisher to do the work of a Publisher. Listing 3 is a rough outline of this.

Class XX is free to extend from some other class if it needs to and it can publish changes to subscribers, whether local or remote, by calling pub.notifySubscribers(). You can also reuse BasicPublisher by subclassing it, but this is not the preferred way. It eliminates the need to delegate the Publisher interface but it reduces the extendibility of the class because the class can no longer be a subclass of any other class.

To use these classes with RMI, the classes that implement Publisher and Subscriber must be remote objects. Without going into too much detail on RMI, let me just point out that any class can be made remote in two simple steps. First, add the following to its constructor:

UnicastRemoteObject.exportObject(this);

and recompile. Second, run the rmic post compiler on the class. That's it. Your class is now remote. Remote publishers can now publish changes to local subscribers in the same VM or to remote subscribers in other VMs.

In summary, these two interfaces and class constitute a far more powerful and reusable embodiment of the Observer design pattern than the JDK's Observer/Observable. They can even be used for remote Observers with RMI. This is just the sort of weapon in your object-oriented arsenal that makes Java programming such a joy.

References
Gamma, E., Johnson, R. and Vlissides, J., "Design Patterns: Elements of Object-Oriented Architecture", Addison-Wesley, Reading, MA, 1995.
Coad , P. and Mayfield, M., "Java Design: Building Better Apps and Applets", Yourdon Press, Upper Saddle River, NJ, 1997.

About the Author
Steven Schwell is a Senior Developer and Java Guru in the New York office of Micromuse, Inc., a leading provider of Service Level Management software. Steve is currently developing a number of large distributed Java apps. He holds a M.S. in Computer Science from Columbia University. Steve can be reached at Steven.Schwell@micromuse.com

	

Listing 1.
 
public interface Publisher extends Remote {  
  public void addSubscriber(Subscriber s)  
    throws RemoteException; 

  public void removeSubscriber(Subscriber s)  
    throws RemoteException; 

  public void removeAllSubscribers()  
    throws RemoteException; 
} 
  

public interface Subscriber extends Remote {  
  public void update(Object pub, Object code)  
    throws RemoteException; 
} 

Listing 2.
 
public class BasicPublisher implements Publisher { 
  protected Vector subscribers = new Vector(2); 

  public void addSubscriber(Subscriber s) { 
    subscribers.addElement(s); 
  } 

  public void removeSubscriber(Subscriber s) { 
    subscribers.removeElement(s); 
  } 

  public void removeAllSubscribers() { 
    subscribers.removeAllElements(); 
  } 

  public void notifySubscribers(Object pub, Object code) { 
    Vector deadSubs = null; 
    Enumeration e = subscribers.elements(); 
    while (e.hasMoreElements()) { 
      Subscriber s = (Subscriber) e.nextElement(); 
      try { s.update(pub, code); } 
      catch (java.rmi.ConnectException ce) { //serious 
        if (deadSubs == null) deadSubs = new Vector(); 
        deadSubs.addElement(s);// must be dead 
      } 
      catch (java.rmi.NoSuchObjectException nsoe){ //serious  
        if (deadSubs == null) deadSubs = new Vector(); 
        deadSubs.addElement(s);// must be dead 
      } 
      catch (java.rmi.RemoteException re) { 
        /*might recover?*/ 
      } 
    } 
    if (deadSubs != null) { 
      e = deadSubs.elements(); 
      while (e.hasMoreElements()) { 
        Subscriber s = (Subscriber) e.nextElement(); 
        removeSubscriber(s);  // forget this subscriber 
      } 
    } 
  } 

  public void notifySubscribers(Object pub) { 
    notifySubscribers(pub, null); 
  } 
} 

Listing 3. 

public class XX implements Publisher { 
  BasicPublisher pub = new BasicPublisher(); 

  /** Delegate Publisher interface to BasicPublisher */ 
  public void addSubscriber(Subscriber s) { 
    pub.addSubscriber(s);  
  } 
  public void removeSubscriber(Subscriber s) { 
    pub.removeSubscriber(s);  
  } 
  public void removeAllSubscribers() { 
    pub.removeAllSubscribers(); 
  } 
  ... 
  ... 
}

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: info@sys-con.com

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.