Java Tip 38: The trick to "Iterator Observers"

Factor out common code and make your Iterators observable

1 2 Page 2
Page 2 of 2

Those readers interested in hiding the nature of their systems' persistent storage should try to design a generic interface for the QueryExecuter that doesn't require explicit method names such as GetEmployees(). Another point to note here is that by encapsulating your queries in a class like QueryExecuter, a more scalable design results. Just consider the impact on your system's design if you later have to replace your RDBMS with a ODBMS and you have designed your system to pass SQL statements and JDBC ResultSet objects around!


As with all idioms and patterns, it is important to use them to solve a problem -- not to introduce complexity. Below I have listed the occasions when the Iterator Observer idiom can be extremely effective.

  • When more than one object is updated by the elements retrieved from an Iterator.

  • When the same iterator client code is duplicated throughout a system.

  • When encapsulating different Iterator syntax in adaptors that provide an Iterate() method.

  • When encapsulating access to queries on persistent data or from remote objects.
Philip Bishop is technical director and a consultant at Eveque Systems Ltd in the U.K, which specializes in designing and implementing distributed object systems using Java, CORBA, C++, and ODBMS.

Learn more about this topic

This story, "Java Tip 38: The trick to "Iterator Observers"" was originally published by JavaWorld.


Copyright © 1997 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2