Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java Tip 38: The trick to "Iterator Observers"

Factor out common code and make your Iterators observable

By Philip Bishop, JavaWorld.com, 09/01/97

Page 2 of 4

Observers

Examples of the Observer pattern can be found in Smalltalk's MVC (Model View Controller), Microsoft's C++ MFC document/view architecture, and Java's own Observer and Observable interfaces. The Observer pattern generally is used to inform clients (Observers) if the state of an object (known as the subject) that they have expressed an interest in changes.

Consider the code in Listing 3 (which does not use the Observer pattern), where a Spreadsheet and a Graph object display different representations of the same data. When the data changes, these objects must be notified so they can update their displays. What would be the impact of adding extra views to the App class? And how you could enable/disable the views being updated?

public  class Spreadsheet {...}
public  class Graph {...}
public class Data {...} 
public class App extends Applet
{
    private Data data = new Data();
    //views
    private Graph graph = new Graph();
    private Spreadsheet ssheet = new Spreadsheet();
    //other views
    private void UpdateViews()
    {
        //Method called if the user has changed something
        graph.update( data );
        sheet.update( data );
        //other interested parties
    }
}

Listing 3: Example without the Observer

Fortunately the Observer pattern comes to the rescue! The Observer pattern decouples the concrete observers from the subject. Listing 4 shows a simple example of how the Observer pattern improves the design in Listing 3. Observer and Observable are part of the java.util package.

public  class Spreadsheet implements java.util.Observer 
{   
    //impl
    public void update(Observable  o, Object  arg)
    {
        //update the spreadsheet with the changed data
    }
}
public  class Graph implements Observer {...}
pubic class Data Extends java.util.Observable  
{
    //inherits all the methods to add/remove and notify 
    //observers from Observerable
    public void ChangeData()
    {
        //change the data then...
        setChanged(); // inherited protected method
        // notifyObservers() will invoke update() on all registered observers
        notifyObservers(this);  //inherited method
    }
}
public class App extends Applet
{
    private Data data = new Data();
    //views
    private Graph graph = new Graph();
    private Spreadsheet ssheet = new Spreadsheet();
    //other views...
    public class App()
    {
        //register the observers with the observable
        data.addObserver( graph )
        data..addObserver( ssheet )
        //add other types
    }
    private void UpdateViews()
    {
        //Method called if the user has changed something
        //update the data object
        data. ChangeData();
    }
}

Listing 4: Example with an Observer

So how do the Spreadsheet and Graph objects in Listing 4 get updated? Basically, the Observer pattern implements a kind of callback from the Observable object to the Observer; take a closer look at the method Data.ChangeData() in Listing 4.

With a brief tour of Observers and Iterators under our belts, let's quickly recap and then go on to examine how we can use the two patterns together.

Summary of iterator and observer design patterns

Here are the basic definitions of the two terms:

• Iterator: An abstract mechanism for accessing the elements in a collection.
  
  
• Observer: The Observer pattern has two participants, Observers and Observables and defines a one to many relationship between them. An Observerable object contains a list of its Observers. When the Observable's state changes it notifies its Observers so that they are updated automatically.

For more information on design patterns, including Iterator and Observer, see "Design Patterns" Gamma et al, Addison Wesley. (See the Resources section for a link to this site.)