Categorization

• Interpreter: Interpreter suggests inventing and representing small languages for reoccurring problems [4]. Translator already presumes the existence of an abstract syntax representation. Translator is well-suited to defining the interpretation part of Interpreter which defines interpretations in member methods of elements (see section 2.2) or by using Visitor.
• Visitor: Visitor [4] has similar motivations as Translator. Yet, besides the fact that Visitor does not cover homomorphic and incremental translations, it also uses a different means of achieving double-dispatch. Visitor relies on the straightforward technique of encoding an arguments type into method names [5]. However, several disadvantages are aligned with this approach:
  • A mutual dependency cycle is introduced between elements and visitors [7]. This impacts recompilation and regression tests.
  • The elements are forced to know about interpretations because of the need to provide an Accept method.
  • One has to provide code for interpreting all elements of a hierarchy, although only a subset will actually be considered by certain interpretations [7].
• Facet: Like Translator this pattern aims at supporting the addition of new and unforeseen interfaces to existing classes without impacting clients that do not require the new interfaces [3]. Thus, both patterns preserve the initial key abstraction, i.e., allow element interfaces with intrinsic properties only. Also, both patterns allow for dynamic extensions of classes. Facet differs in that it mainly aims at role modeling and does not take translations or incrementality into account.
• External polymorphism: An alternative way (cleverly exploiting C⁺⁺ templates) to achieve polymorphism with classes wich have no common ancestor [2].
• Acyclic Visitor: The dependency cycle in the original Visitor design [4] caused many suggestions for improvements such as Acyclic Visitor [7] and Dynamic Visitor [10]. Both alternatives also address the issue of partial visitations, i.e., when a particular interpretation does not need to be defined on all elements. Translator may deal with such a situation as well, since there is no obligation to provide a complete set of specialized functions.
• Serializer: Because Serializer [12] is a specialization of Visitor, it is also related to Translator. One can think of Serializer as translating objects to a flattened form (e.g., for persistence). In fact, Translator might be more appropriate in some cases since it does not require objects to know about their ability to be serializable.