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!

Conclusion

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

Related:
1 2 Page 2
Page 2 of 2