Editing Visitor pattern (section)

== Application ==
Consider the design of a 2D [[computer-aided design]] (CAD) system. At its core, there are several types to represent basic geometric shapes like circles, lines, and arcs. The entities are ordered into layers, and at the top of the type hierarchy is the drawing, which is simply a list of layers, plus some added properties.

A fundamental operation on this type hierarchy is saving a drawing to the system's native file format. At first glance, it may seem acceptable to add local save methods to all types in the hierarchy. But it is also useful to be able to save drawings to other file formats. Adding ever more methods for saving into many different file formats soon clutters the relatively pure original geometric data structure.

A naive way to solve this would be to maintain separate functions for each file format. Such a save function would take a drawing as input, traverse it, and encode into that specific file format. As this is done for each added different format, duplication between the functions accumulates. For example, saving a circle shape in a raster format requires very similar code no matter what specific raster form is used, and is different from other primitive shapes. The case for other primitive shapes like lines and polygons is similar. Thus, the code becomes a large outer loop traversing through the objects, with a large decision tree inside the loop querying the type of the object. Another problem with this approach is that it is very easy to miss a shape in one or more savers, or a new primitive shape is introduced, but the save routine is implemented only for one file type and not others, leading to code extension and maintenance problems. As the versions of the same file grows it becomes more complicated to maintain it.

Instead, the visitor pattern can be applied. It encodes the logical operation (i.e. save(image_tree)) on the whole hierarchy into one class (i.e. Saver) that implements the common methods for traversing the tree and describes virtual helper methods (i.e. save_circle, save_square, etc.) to be implemented for format specific behaviors. In the case of the CAD example, such format specific behaviors would be implemented by a subclass of Visitor (i.e. SaverPNG). As such, all duplication of type checks and traversal steps is removed. Additionally, the compiler now complains if a shape is omitted since it is now expected by the common base traversal/save function.

=== Iteration loops ===
{{See also|Iterator pattern}}
The visitor pattern may be used for iteration over [[Container (abstract data type)|container]]-like data structures just like [[Iterator pattern]] but with limited functionality.<ref name="Budd1997">{{Cite book |last=Budd |first=Timothy |url=https://www.worldcat.org/oclc/34788238 |title=An introduction to object-oriented programming |date=1997 |publisher=Addison-Wesley |isbn=0-201-82419-1 |edition=2nd |location=Reading, Mass. |oclc=34788238}}</ref>{{Rp|page=288}} For example, [[iteration]] over a directory structure could be implemented by a function class<!-- <- this is not a mistake, it means class Function {...} --> instead of more conventional [[Loop (programming)|loop pattern]]. This would allow deriving various useful information from directories content by implementing a visitor functionality for every item while [[Code reuse|reusing]] the iteration code. It's widely employed in Smalltalk systems and can be found in C++ as well.{{r|Budd1997|p=289}} A drawback of this approach, however, is that you can't break out of the loop easily or iterate concurrently (in parallel i.e. traversing two containers at the same time by a single {{Code|i}} variable).{{r|Budd1997|p=289}} The latter would require writing additional functionality for a visitor to support these features.{{r|Budd1997|p=289}}