This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Why interpreter is the pattern? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Why interpreter is the pattern?" Watch "Why interpreter is the pattern?" New topic
Author

Why interpreter is the pattern?

Zee Ho
Ranch Hand

Joined: Jul 20, 2004
Posts: 128
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.


SCJP 1.4<br />SCWCD 1.3<br />SCJD<br />SCBCD<br />IBM Xml Cert in progress
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
B.Sathish
Ranch Hand

Joined: Aug 18, 2005
Posts: 372
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

Joined: Jan 07, 1999
Posts: 6920
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.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Zee Ho
Ranch Hand

Joined: Jul 20, 2004
Posts: 128
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

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Zee Ho:

Is it what you mean?


Yes!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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).
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Why interpreter is the pattern?