The Interpreter design pattern provides a solution:
(1) Define a grammar for a simple language by an Expression class hierarchy.
(2) Represent a sentence in the language by an AST (abstract syntax tree).
(3) Interpret a sentence by calling interpret(context) on an AST.
Describing the Interpreter design in more detail is the theme of the following sections. See Applicability section for all problems Interpreter can solve.

• (1) Define a grammar for a simple language by an Expression class hierarchy:
  • Define an interface for interpreting an expression (AbstractExpression | interpret(context)).
  • Define classes (TerminalExpression) that implement the interpretation.
    "[…] many kinds of operations can "interpret" a sentence." [GoF, p254]
    Usually, an interpreter is considered to interpret (evaluate) an expression and return a simple result, but any kind of operation can be implemented.
  • Define classes (NonTerminalExpression) that forward interpretation to their child expressions.
    
• (2) Represent a sentence in the language by an AST (abstract syntax tree):
  • Every sentence in the language is represented by an abstract syntax tree made up of TerminalExpression instances (tExpr1,tExpr2,…) and NonTerminalExpression instances (ntExpr1,ntExpr2,…).
  • The expression objects are composed recursively into a composite/tree structure that is called abstract syntax tree (see Composite pattern).
    Terminal expressions have no child expressions and perform interpretation directly.
    Nonterminal expressions forward interpretation to their child expressions.
    "The Interpreter pattern doesn't explain how to create an abstract syntax tree. In other words, it doesn't address parsing. The abstract syntax tree can be created by a […] parser, or directly by the client." [GoF, p247] [BGI]
• (3) Interpret a sentence by calling interpret(context) on an AST.
  • See also Implementation and Sample Code.