Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why interpreter is the pattern?

 
Zee Ho
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have read sth about the Design pattern recently, but I do not understand why people treat the interpreter as one of the patterns. It does not make sense. For the rest patterns they either provide benefit in decoupling, hidden detail, better abstraction or more healthy structure, but all those do not work for the interpreter. It is more like a common programming task.

Why people still keep it in pattern? it seems interpreter does not have the same mother with his sibling.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wondered the same, until I read "Refactoring to Patterns". Then I realized that I misunderstood the pattern. I always assumed that it was about building an interpreter to handle a language external to code. But what it in fact seems to be about (in my current understanding) is making code more flexibel by making an implicite language already existing in the code explicite.

An example for an implicite language might be a set of search methods in a DAO:

searchByName("Ilja Preu�")
searchByAge(36)
searchByAgeBetween(7, 42)
searchByNameAndAge...

Replacing this by the Interpreter pattern, that code could look more like

searchBy(name("Ilja Preu�"))
searchBy(age(exactly(36)))
searchBy(age(between(7,42)))
searchBy(and(name("Ilja Preu�"),age(between(7,42))))

Note that the above still is pure Java code - the "language" we are talking about is not a new programming language, but more like a domain language as represented by the existing methods and how they can be combined.

The Interpreter pattern allowed us to decouple the search criteria from each other, so that we can combine them in new ways without having to write a new method for each combination.
 
B.Sathish
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is this really the interpreter pattern? I read in HFDP that the interpreter pattern is used to build an interpreter for a simple language. Each grammar rule is encapsulated in a separate class which has an interpret() method that takes the input stream to the source program to be interpreted as its argument. Each class parses the program applying the grammar rule to it. You can add grammar rules by adding new classes and change existing ones by changing the appropriate class. Isn't this the interpreter pattern? What you said about search criteria is no way related to this..
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For me the whole point of the interpreter pattern is that it decouples the implementation of some process from the compiled code which uses it.

As a concrete example:

In the initial version of my Friki software, processing of entered text (to convert URLs to links, for example) was built-in to the source code. This made it impossible to change without recompilation, which in turn meant that anyone wishing to make even a small change would need to have a complete build system and all the dependent libraries in place.

In the current version, Friki instead reads a sequence of transformation instructions (which consist of a class name and some parameters, typically regular expressions) from an external text file. When a page is processed, these loaded instructions are interpreted in sequence to perform the transformation.

Now, anyone with a working installation can tinker with the processing rules with no rebuilding necessary.

Note that these processing instructions are only a "language" in a very theoretical way. They make no sense in any other context and can not be used for any other programming tasks.
 
Zee Ho
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja Preuss, you offer a very interesting example, so I guess what you mean is

interpreter actually convert the "word" processing to "object" processing, object is obviously easy to control, If the internal logic of your SearchBy method implements properly, I can add any new seach criteria without changing the current code.

Is it what you mean?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Zee Ho:

Is it what you mean?


Yes!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by B Sathish:
Is this really the interpreter pattern?


Well, it is at least close. You are right that the symbols aren't parsed from text, but defined in java code. But the rest works exactly the same: We have a composite of non-terminal symbols (age, and) and terminal symbols (name, exactly, between) (actually what you see in the code are factory methods which create the symbol objects), probably one or more abstract superclasses for the symbols, and a client which executes the symbol composite (the searchBy method).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic