Applicability

Use the Translator pattern for

• Adding semantics. When you want to add an interpretation (even without having planned for it) to a number of classes that have different interfaces, Translator allows accessing the heterogeneous interfaces individually. The classes need not belong to the same hierarchy or library.
• External functionality. Adding interpretations outside of elements avoids bloating the elements' interfaces with extrinsic concepts. Also, if interpretations require additional servers (e.g., environment lookup for type-checking) the interpretations, as opposed to the elements, will depend on the servers, i.e., require recompilation in case one server changes.

• Incrementality. When small changes to big structures should not cause reevaluation of the whole structure, exploit the homomorphic properties of Translator and use the intermediate structure (see figure 6) for storing computed results.

Do not use the Translator pattern in case of

• Unstable elements. When new elements are frequently added to the source structure it is probably better to define the interpretations in the elements. Otherwise, one has to constantly change all associated function packages (see figure 4 and also section 2.7).
• Space constraints. Unless you can make use of the benefits of a target structure (see section 2.7 Separation.), avoid the space overhead by directly translating to results.