73: Design Patterns: Interpreter.

The interpreter behavioral pattern allows you to solve common problems by expressing those problems in a simple language. You first need enough problems to make this pattern worthwhile. And this pattern is great for allowing other people to contribute to your application without writing actual code. You define a language that can be used to describe different problems sort of like how a math formula solves a problem. You have different math formulas to solve different kinds of problems. And each formula can solve different specific problems by substituting different values into the formula. This pattern relies heavily on the composite design pattern. In fact, it’s really just a composite structure where the objects are instances of classes representing the rules of your language. This is called your grammar. Each of these objects defines a method called evaluate that needs a context to be passed to the method. The context is just the specific values that you want to evaluate. The composite pattern is great for calling the evaluate method for each object in the structure. That’s all there is to this pattern. It’s a simple pattern with a complicated description though in the Gang of Four book. This episode provides more information with an example from the adventure game. I explain how you can use this pattern to solve a wide array of spell effects and even how to let game designers have direct input into how the spells work by writing formulas that can be interpreted with this pattern. Listen to the full episode or you can also read the full transcript below. Transcript The basic description says that this pattern begins with a grammar then defines a representation for that grammar as well as an interpreter and then uses the interpreter to interpret sentences. Wow, I think I confused myself on that one. Let me explain this in a completely different way that hopefully we can both understand. And if my explanation doesn’t quite fit with what the gang of four intended, then I say it’s their fault for writing such a ridiculous description. This is a pattern that without somebody to explain it, we would all, yes, even me, just drift off into a daze. Okay, here it goes. I’ll start with a description of a problem and then show how you might use this pattern to help. First of all, you need a bunch of common problems. If all you have is a single or even a fixed number of specific problems, then you’re probably better off writing specific code to solve them. This pattern applies when you have enough problems that you get tired of solving them and they’re all similar and not very complicated. What kind of problems? Well, let’s take the adventure game as an example and say we want to allow for many different kinds of magic spells that can be cast on a distant target. And let’s also say that the spell behavior should change as the hero gains experience and gets better. Now, if you only have a couple spells, maybe one throws a ball of fire and another shoots lightning, then you might be better off representing these with their own classes. But if you have game designers that are conspiring against you by coming up with new spells almost daily, then you’re going to need a better solution. Programmers, you see, have a special kind of laziness. We’ll work really hard to automate something so we don’t have to do that work anymore. And a really good way to avoid work is to get those designers to do it instead. So how should you approach this. Well, this pattern says we need a language. A grammar is just the rules that define a language. Our spell language will probably need things like level, distance, spread, immediate effect, and ongoing effect. Maybe more but this should be good enough for this explanation. ◦ Level will define how experienced the hero is. ◦ Distance will define how far the spell can reach and should increase based on level. ◦ Spread will define how