Content deleted Content added
GlenPeterson (talk | contribs) →Not confined to language processing: new section |
|||
Line 56:
The "Interpret(Context)" methods in TerminalExpression and NonTerminalExpression are in italics, which indicates they are abstract. Clearly they are meant to be concrete implementations of the abstract method "Interpret(Context)" in AbstractExpression. The "Interpret(Context)" should have italics removed in the *subclasses*. 14:41, 15 April 2012 (UTC) <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/78.105.136.120|78.105.136.120]] ([[User talk:78.105.136.120|talk]]) </span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
:It has come to my attention that if this is a GoF diagram then it is probably in OMT and not UML. My reasoning above is for a UML diagram, I am not aware of correctness for OMT. I'll leave the comment above just in case some other unassuming developer comes across here and expects to be seeing UML. :) 20:37, 15 April 2012 (UTC)
== Not confined to language processing ==
The point of design patterns is to recognize general patterns so that they can be applied anywhere. Unfortunately, the description of this pattern seems to be unnecessarily tied to a specific example both in the GOF book and in this article. A good counter-example would be to use a class hierarchy (or tree of interface implementations) of functional objects to determine the taxonomic classification of a specimen, each level of the tree delegating the identification to the proper child branch until the specimen is identified. There is no grammar to interpret, yet this is the same pattern of code.
A more general and useful definition might be a "Rules Engine" as [http://www.oodesign.com/interpreter-pattern.html OODesign.com] suggests. Really, it's a tree data structure of functional objects (each implementing the same single method). The functional objects "rules" delegate to one another until a terminal object (rule) is reached. The objects could be related through an interface and through the logic in their single implemented method instead of through an object-oriented inheritance hierarchy. If no-one finds somewhere that this has already been stated clearly, I can add it to my blog and someone who doesn't know me can come along some day and use that as a source to improve this article.
| |||