The VISITOR pattern lets you add behavior to a class hierarchy without extending it. It localizes structure into a set of accept() methods, and behavior into a set of VISITOR objects. Although structure and behavior are not the best examples of aspects that cross-cut system functionality, the VISITOR does have basic AOP characteristics: without it the structure and behavior decisions are scattered throughout the tangled code instead of being dealt with separately. The VISITOR thus provides ``a solution to an aspect-oriented problem in a context.''
One can argue (or rather, be mis-understood [2]) that there is very little need for the VISITOR pattern if you use a multi-method object-oriented language such as CLOS or Dylan. While this is true for the object-oriented internal workings of the VISITOR (e.g., the double-dispatch ``ping-pong'' implementation in C ++), it is not so for its aspect-oriented purpose. In a way, such an argument would have said that adaptive programming [4], an aspect-oriented technique explicitly applying the VISITOR pattern, is not useful for CLOS, although the CLOS community developed a useful version of DEM [3] (a tiny version of Demeter) in CLOS. The localization of structural information is the aspect-oriented ingredient of the VISITOR which prevails.