Design Patterns Poll   

Pattern	Votes
Abstract Factory	++++++
Builder	+
Factory Method	+++++++++++
Prototype	++
Singleton	+++++++++
Adapter	+++++
Bridge
Decorator	+++++
Facade	+++++++++
Flyweight
Composite	++++
Proxy	+++++
Command	++++++++
Observer	++++++++
Visitor	++++
Interpreter	+-
Iterator	++++++++++
Memento	+
Template Method	+++++++++
Strategy	++++++++++
Mediator	++
State	++
Chain of Responsibility	+++

Re: The '-' I gave the Interpreter

While the Interpreter is a useful idea, It doesn't really feel like it fits with the other patterns. Perhaps it's a case of the pattern not being described as well as the other patterns. With most of the patterns, the GoF book describes the class and object hierarchies and how they can be adapted to a particular problem. With the Interpreter, however, they describe a different type of problem solution (design a grammar) and the class/object diagrams to implement that solution. The way to implement the grammar is well described, but the uses of grammars to solve a variety of problems is merely glossed over at best. In other words, they've described how to solidify my grammar into implementable classes, but NOT what problems are solvable with such grammars.

As the Implementation section for the Interpreter mentions, the Interpreter and Composite patterns share many of the same issues. I think it would have more sense to mention grammar interpreters in the Composite chapter as an example use of that pattern.

-- RyanMcGuire?

In my opinion, Interpreter solves a very specific problem, that is it has a very specific context, and therefore deserves to be its own pattern. I have to admit, though, that I didn't fully understand the intent of the pattern until I read the corresponding chapter in "Refactoring to Patterns".

-- IljaPreuss