The Interpreter design pattern solves problems like:
How can a grammar for a simple language be defined
so that sentences in the language can be interpreted?
See Applicability section for all problems Interpreter can solve. See Solution section for how Interpreter solves the problems.

• "If a particular kind of problem occurs often enough, then it might be worthwhile to express instances of the problem as sentences in a simple language. Then you can build an interpreter that solves the problem by interpreting these sentences." [GoF, p243]
• Specifying a search expression, for example, is a problem that often occurs. Implementing (hard-wiring) it each time it is needed directly within a class (Context) is inflexible because it commits (couples) the class to a particular expression and makes it impossible to change or reuse the expression later independently from (without having to change) the class.
• That's the kind of approach to avoid if we want to specify and change search expressions dynamically at run-time.
• For example, an object finder with arbitrary (dynamically changeable) search criteria.
  Instead of hard-wiring a search expression each time it is needed, it should be possible to define a simple query language so that search expressions can be speci­fied and interpreted (evaluated) dynamically (see Implementation and Sample Code / Example 2).