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.
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
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:
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
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..
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.
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?
Joined: Jul 11, 2001
Originally posted by Zee Ho:
Is it what you mean?
Joined: Jul 11, 2001
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).