This is a success story about using a traversal/visitor style 
of design/programming as used by Adaptive Programming (AP)
in a commercial project at Hewlett Packard.

-- Karl Lieberherr

The traversal/visitor style of programming has been applied to a project 
at Hewlett-Packard in Vancouver by Debra Bacon. A conventional C++ 
environment was used without tool support for Adaptive Programming. 
The project was very successful. The manager of the project, Rich 
Johnson, said:
I believe the traversal/visitor approach has been very beneficial in 
this application... The quality level of this project is high and is 
currently being used to install printer drivers. The code will ship to 
customers in the near future.
The project involved a complete redesign and implementation of an 
existing application using the traversal/visitor approach. A significant 
amount of traversal reuse was noticed in the project. The traversal 
methods were reused a minimum of four times during the initial 
development. These methods are expected to be reused in any future 
enhancement. The size of the program shrank in size and at the same time 
it became more flexible.

The manager of the project indicated that the traversal/visitor approach 
greatly increases the return on this software asset and reduces the 
complexity at both the project management level and an engineering level 
since the code is not shared (i.e., it is clearly owned and managed).
After using AP principles to guide the application design, the 
implementation had few AP related issues. The application classes were 
simpler because the collection issues were removed to reusable 
collection classes. Consequently, unit testing was simpler because the 
methods acted upon only one element.
The reusable collection classes were simpler because only the insertion, 
search, and traversal methods were defined. Simple unit test harnesses 
could validate the methods. Once tested for the harness, they were 
validated for use in the application without retesting.
The Visitor classes were slightly more complex than either the 
application or collection classes because they contained knowledge of 
the application class being visited and the collection class being 
traversed. However, several generic Visitors were created to Trace, 
Delete, and to invoke the objects' "Do" method. These generic Visitors 
contained no class specific state data nor class specific method 

It is important to note that the visitors contained the data and control 
structures necessary to add incremental functionality enhancements while 
using only the classes' public interface. To adapt to a new class 
architecture, only the visitors would require changes (if the new 
objects' public interface was complete). The visitor seems to be a key 
to adaptable software in a conventional object-oriented environment.
The average McCabe cyclometric complexity of the methods is 2.34 and the 
highest is 13. The low average complexity seems reasonable because 
complexity in part measures the number of branches and loops which were 
reduced each time a visitor pattern replaced the looping code of a 
traversal. The reduced complexity is also attributable to other factors 
such as the use of inheritance.
When compared to the benefits described above, the costs were minimal. 
During the design phase, we spent additional time learning AP concepts 
in conjunction with UML notation. Since we had been designed using 
Fusion notation, we adapted the AP graph analysis technique to use our 
Fusion documents. A significant amount of time was spent teaching and 
otherwise expounding upon AP concepts, UML notation, pattern based 
programming, visitors and the like. During the implementation phase, we 
implemented the hierarchy of Visitor and Element derived classes 
required for our implementation of AP concepts. It could be argued that 
the Visitor and Element code replaced a larger amount of inline 
traversal code. However, the Visitor code was conceptually new, 
therefore a cost was incurred.