We continue our season of software architecture patterns and more by reviewing the interpreter pattern. This one may seem familiar. It has been discussed in other areas of software development. However, it is worth refreshing our memory on this helpful solution.
The Interpreter Pattern DefinedThe way this works is to start from a client, and given a context; we receive an expression. That may be a very simple or complex series of "sentences." Next, the expression is broken down into parts that are individually interpreted. Finally, the combined results are sent back. That gives us yet another pattern that involves breaking the big problem down into smaller pieces. Thus, it is easier to solve.
Applying The PatternThere are many opportunities for us to create a language in software and then use an interpreter. Likewise, every computer science student has spent some time with these sorts of problems. Of course, every computer language has this pattern implemented in some way. While the interpreter pattern may seem difficult to apply, it has potential in many areas. Therefore, it is worth considering as you design your approach. As you will see, it is another way to chop up a big problem into more manageable bites.
Challenges This pattern is based on splitting up the work (interpretation) into stand-alone steps that can be mixed and matched as needed. The challenge is to avoid interdependencies wherever possible. The less each unit of work links to others, the easier it is to build and re-use the solution. There is also the problem of walking through a sentence or complex expression and breaking it into component parts. For example, think of diagraming a sentence. It is not always a natural way to think about a request. However, you can build from simple expressions up to complex ones. Next, use testing to confirm you are on the right track. Thus, the solution often ends up much easier to maintain than a holistic approach. The focus is on components instead of the permutations of expressions.