Traversals are ubiquitous in object-oriented applications. A traversal is a navigation through a group of related objects with the purpose of accomplishing some task. A single method is a degenerate traversal which visits only one object. But most of the time, a task needs the collaboration of several objects which know about each other.
The way the objects know about each other is bound to change as a project evolves. For example, suppose another task requires different object relationships which need to be integrated with the current object relationships. But then many of the tasks which used the old object relationships need to be updated. This problem of fragile object relationships is called the small methods problem or structural anomaly [8,6]. While each class has minimal coupling and works on its private data, the implementation of a task is usually spread across many classes. The implementation assumes a particular class organization that hard-wires structural knowledge paths into the program. This leads to a weakening of encapsulation and a significant maintenance problem.
This demonstration presents a solution to the structural anomaly for Java software developers. The idea is to let the programmers express a traversal strategy instead of a detailed traversal. The traversal strategy turns out to be much more robust under changing object relationships and therefore simplifies the maintenance of programs. Writing the traversal strategy is a form of preventive maintenance since it simplifies maintenance later. Preventive maintenance sounds like more initial work for the programmer, but indeed the opposite is true since the programs become simpler.
Several companies see the benefit of both simpler and more maintainable programs as very important and have adopted AP for C++. Demeter/Java makes AP available to the Java community.
The simplest form of a traversal specification is: from Company to Salary, where Company and Salary are classes in some class diagram. Given a Company-object, the traversal will find all Salary-objects reachable from the Company object. We recognize the strategic nature of a traversal specification: not all the detailed traversal steps, such as go from Company to Divisions to Departments to Employees to Salary, are expressed but only the overall strategy to reach all Salary-objects. When a class diagram is given, we can automatically expand the strategy into a detailed set of traversal methods. AP offers a little language to express traversal specifications allowing one to constrain traversals in both positive and negative ways. The semantics of traversals is defined formally in [5].