The Interpreter Pattern

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We're continuing our season where we're talking our way through software architecture patterns and anti-patterns. We're starting out with the patterns, trying to have a positive outlook, I guess. In this episode, we're going to focus on the interpreter pattern. Now, this may sound familiar because we have run into an interpreter pattern before. We ran into this when we talked about just general software development patterns. So there is definitely a link here between that prior approach and the architecture approach. You will find a lot of similarities. It's just a matter of scale, almost more than anything else. You can have an interpreter done with very small pieces and have an object or a couple of objects that are interacting, or you can blow it all the way up to an entire software architecture. Now, this is a pattern, as we mentioned before, that has some very, I guess, specific types of things that it's commonly used for, but it can also be used in a wide range of places. Now, with the idea of an interpreter, you probably assume or somehow relate that in your mind to a language. Typically, an interpreter translates from one language to another. So if you, you know, the United Nations, somebody is, let's say they only speak French, they're listening to a speaker speaking in German, then you may have an interpreter there that is listening to German and says in French, you know, translates it, says this is what they're saying. And interpreters are not always word for word. There's context and then there's combinations of, in a language, of words that have a slightly different meaning or give meaning to those words. And we'll see that when we're dealing with an interpreter architecture or other, when we're dealing with this pattern in general. And while we, we will specifically in our design be able to address each item, each expression, we also will be able to link those together. And that may actually give us a slightly different approach where the sum is, you know, the sum of the parts is not the same as the whole. So you get things a little bit different, but that's okay because the key to the interpreter pattern is we want to be able to get these expressions, these words, you know, to keep it sort of simple, possibly a word at a time, possibly a sentence or a paragraph or more. And then the pattern is going to apply those things, is going to, well, is going to interpret those things, is going to do something with those things. Now in a, if you want to do an interpreter pattern for mathematical expressions, then you're going to have things like a number, operators, and maybe some sort of grouping, you know, parentheses, brackets, things like that. And so as you're going through with your, when you're building out your design, you're going to be able to, or have to be able to handle the operators, whether they are addition, subtraction, multiplication, whether they're logical, you know, greater than, less than, equal, not equal, things like that. And then also values themselves. Is it a, is it a number value, is a string value, is it a Boolean value, so on and so forth. So that would be for math. have all these, instead of trying to solve it like an entire expression and build software that handles all of the different ways to interpret, to have that expression put to you. Instead, you have this interpreter that just breaks it down into its parts and then pulls it back together to give you an answer. Think of the most, something very simple, like two plus three. There's three things there. There's the number two, the number three, and then the operator plus. Now just that one, two plus three, three plus two, same thing. Same thing if you did two times two, three times two. Or I'm sorry, two times three, three times two. Now obviously order matters in some cases. So two minus three is not the same as three minus one. But what we do instead of trying to have something that says, okay, I need to handle two plus three and then I need to handle three plus two and then three times two and then two times three. All of those, we break it down into the parts and we just know that really what it is, is this pattern to figure it out. And the pattern is breaking into the values, the two and the three, and then the operator, determine any operators that are involved, and then figure out if we have some sort of an order to it. It may or may not actually, order may or may not matter at all, but particularly if you know that you have to move left to right or right to left in the interpretation of that sentence, we'll call it that expression. Then we can use interpreters to essentially have our own language. That we can, and the interpreter will allow us to use that language to generate results. You may, for example, have some sort of a batch process where you have a bunch of different steps and you want to be able to use those steps, but be able to apply them in different orders or different replications of it. You may want to do step one, step two, back to step one, do step three, do step one again, do step eight, something like that. So instead of having to build that logic out, and for all of the different ways that steps could go, if each of those is a self-contained expression of some sort, when you do step one, you have some inputs, you have some outputs. And again, this is going to sound familiar to some of the other patterns we've run into, because what this gives us is, again, a way to take a bigger, larger problem and split it into smaller pieces. This one's a little different because we're not just building a specific solution. We're allowing the solution itself to be a little bit flexible because the problem we're solving this time is actually how do I handle commands versus how do I solve a specific problem? When you think about that, when you think of software as a series of commands, then the interpreter allows you to take that series of commands, assess it or translate it into some sort of work, some sort of data manipulation or things like that, and then kick out a result, assuming that there is a result. We can use this to take these, so we can take things like components, and we're close enough to them, we can have a series of functions or activities, and then we can send the system a sentence basically that is some sort of combination of those and then see what the result is. And so it becomes a really, I'll say, elegant way to solve some problems that are out there. For example, think about a telemarketer script. They have certain questions that they're going to ask. You can think about this actually on a test as well, like an educational test, because what you do is you have certain questions that are asked. And what you may want to do is set it up so there's different orders of, questions are in a different order. And maybe some are not asked in certain cases. It could be random. It could be something that it's certain plate like. There's always going to be geographical things. So there may be questions that, how often do you go to the ocean? Well, if they're nowhere near the ocean, you don't need to ask that question. Or do you live in the mountains? You may have already been answered somewhere else. So we may not want to, we may not need to build that. Now some of this is, you can do this ad hoc. So you can build your flow based on answers, based as you go and say, okay, with this answer, do I go to A, B, or C? Or you can right away say, this person's coming in via phone. So here is the series of things we want to do. They're coming in via email. So here's a series of things we want to do. Maybe you want to randomly do it occasionally. Is do a little bit of a mix and match so that you can figure out what's the best approach. What's the most efficient way to get all of these tasks done. There's other ways you can do it. But with an interpreter, it allows you to build those things. Or they maybe they already exist. An interpreter simply says, I'm going to take requests that are typically are going to be complex. So there can be more than one expression or one request. And I'm going to be able to parse that and then have the system do the things that have been requested of it to do. There are many ways that we can essentially provide a dynamic or user based approach to utilizing the components or those pieces that we've built. It does have a lot of flexibility beyond just maintenance and even scalability to some extent Because you have all of these things, all of these expressions, all of these actions that you can do. If you think about it, you've got like this pool of actions. And the way you figure out which actions you're going to do is through the interpreter is through you give it a sentence, a string of information says this is what I want it to do. And then the interpreter says, oh, that means I have to call these things in this order. And then that can be very powerful. Again, when you think of like scripts are off, like dialogue scripts that you may get from in a phone call, those kinds of things. There's a lot of times where you want to send that. You may want to have a simple way within an API to do or something along those lines to do very complex stuff. So instead of doing individual calls, you send this string in that is actually encoded essentially to say these are the calls I need to make. And then the interpreter takes that stuff, breaks it out into its parts, calls out to the things that need to be called out to, gathers the results, sends it all back. So there's multiple uses of this beyond just thinking about translating a language. When you think about it as telling the system in a dynamic fashion what to do, then you'll start seeing, I think the doors open on much more, a lot, a broader range of approaches that you can use at least, and also ways that you can make the flexibility of the system more available to the clients, to the users. It's not really, again, it's not really a complicated pattern because when it comes right down to it, we have these pieces of work and then we have something that says given a request, I'm going to go activate or utilize these pieces of work. So it gives you a lot of flexibility without a very complex solution required. Because really at the end of the day, it's just read that sentence and have a way to be able to parse it out. It could be a very well-defined, it could be like English language and think about diagramming sentences and something that can be sort of complex. Or it could be as simple as your request could be a bunch of comma separated values or delimited values in some way where each value, let's say, is a number and that number calls a specific, ties to a specific function. So if I want to, which like the batch thing, each one could be a step number. It could just be a comma separated list of steps and I could say, oh, OK, I want to do steps one, two and three. Oh, wait, now I've got a different request. He wants to do require steps two, four, six and eight. Or this one wants to do steps one, two, three, four, five, six, whatever it is. Is that allows us to have that functionality there? And we'll say target, I guess, target the work that is done to the specific request, because if that thing isn't there, if there's like step two isn't in your list of steps, the step two code doesn't even need to be touched. It may not even exist. It may be something that until a two can be tied to something, it just ignores it. There's things like that that you can do to allow you to again, take a larger problem, maybe break into something smaller, but in this case also allow the client, the customer, the requester to sort of craft their own solution. I think that's enough for the interpreter. We will continue our discussion of software architecture patterns next time around. We're getting close to the end of going over the pattern side of it, and we will start flipping into some anti-patterns. Again, you're going to see some things that are going to be popular or common ideas that are going to recur as we talk through some of these patterns and anti-patterns, which is probably not a bad thing. If you think about it, software in general has certain, we'll call them best practices or ways to approach problem solving. And so you're probably going to see those those kinds of steps taken over and over again as we look through patterns that sort of makes sense, that probably in a sense validates some of these patterns. But that being said, I've taken enough time up for your day, so let's get out there and get some work done. Go out there as always and have a great day, great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. There are two things I want to mention to help you get a little further along in your embracing of the content of Develop-a-Nor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Develop-a-Nor site. You can also find it on Amazon, search for Rob Brodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time we talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at develop-a-nor.com if you would like more information. Now go out there and have yourself a great one.