Rosetta Stone pattern

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We're continuing our season where we're looking at patterns and any patterns of software architecture. In this episode, we're going to look at a pattern we're going to call Rosetta Stone. Now Rosetta Stone, you may think of a like a multilingual application for teaching you how to speak, read and such a foreign language. That's actually based on the historical Rosetta Stone, which was a basically it was one of the first multilingual documents in I guess maybe in history or at least that we know of. It was basically a situation where there was a decree that went out and on the stone that decree was in multiple languages and that allowed some translations that before that we really didn't have. That's basically one of those where you've got one and you know that it's the exact same text in another language. It allows you to basically do some get at least some rudimentary translations and it was a pretty good start from there. So it's the idea of a Rosetta Stone is a way to bring disparate things, languages even more specifically from history, bring those together and then translate into like a common thread. And that's what this pattern is about. It's use is going to be most often when we are integrating with multiple systems. And it's really the key there is that we're bringing in and then talk out and sending out or talking to these disparate systems. They could be the same as far as very much the same fields, maybe even the same names, the same data types and things like that. But more often than not, there are differences. They may be labeled a little differently. They're particularly like, you know, text strings may be a little different in sizes, date formats may be a little different. There's all kinds of things like that. And so what we do with this pattern is we say, you know what, first we're going to pick the we'll say the correct or the way we want this modeled. Basically it's based on all of those other inputs so that you've got a it's not quite a superset, but pretty close so that if any of these other systems have values that they need to send in and then also to get received back from us, that we take those into account. You can also think of this almost as like a sort of like a hub and spoke kind of an approach is that you've got this central structure, we'll say that is used to store our data and our maybe even some logic. And then all of these different pieces, these different systems, when their data comes in, the first thing we do is we translate into this one, you know, this common format. We work with the format and then when we need to report back out or send back out to those systems, we have a different conversion that goes from our standard format to something external. Now, the bonus here is that in many cases, that external thing can actually be not system specific. If you think of, for example, a nice little XML document, what you can do is you can have all of these things come into your one format and your one format just exports an XML document and then all those other systems are left to pull their specific information out of that XML document. Or it could be anything really, it could be common separate values, it could be whatever, doesn't matter. The key here is the inside, the coming in, and that's where that translation part is. Because we have these systems that have their formats, their structures, their labels, and we need to find a way to convert those to something that we can work with in the most productive way. If we instead wanted to leave all of those separately, then we would have to work with each of the specific integrations and write code for that, as opposed to convert everything into one format and work from there. Now, it's not just integration with other systems. There are situations where we essentially can use this same approach for portions of our application that are, I guess, extensions or if you think of like a plug and play kind of approach where there's a general case that we're solving for or that we're working with and then there's all these customizations or extensions. What we want to do is have that one, that general case is taken care of. We can do that and essentially not have to repeat that logic or that structure over and over again. Instead, we have this core and then we have these other pieces that basically work with the core. They translate into the core and then when the core generates results, you can always translate it back out. For example, and this does trip along some other patterns we've talked about, but think about a parent-child relationship in an object-oriented sense. We've got an employee, but then we also have a subclass of employee that is a manager. Now, the manager is going to have slightly different information, but with the Rosetta Stone pattern, what we do is we have a piece of a chunk of functionality. We have that employee object, that structure. That's basically what we use. That's basically what we're passing around. A manager object would come in, be converted into essentially an employee. You do what you need to do with it and then you pass it back. It's from a class, a traditional class hierarchy. That's exactly how it works. Is that employee object has its employee-specific stuff and then the manager essentially works with those pieces. Then when it wants to do manager-specific stuff, it has to address the manager class. It's not a perfect analogy because typically Rosetta Stone is not extensions of. It would be more like instead of the manager inheriting from the employee, you instead had maybe a helper class that was a manager. The manager had its own stuff and maintained its own stuff, but it was not an employee. That's a little different. That's a little different view. That's why typically when you see Rosetta Stone, it's going to be with integrations with other systems or multiple formats. For example, if you want to read in, you're reading in data, but sometimes it comes in CSV, sometimes it comes in XLS, sometimes it comes in XML. What you would do is regardless of what the file format is, is you read it into maybe like an internal structure that is the same regardless of whatever that input file format is and then you start working with it. Instead of putting logic in as your separate logic for we read in a CSV file, we do a bunch stuff. We do an XML file. We do a bunch of stuff. With each of those, the only code we're writing is to pull that format into a standard format and then we move on from there. That allows us with extensions or integrations and extending the number of integrations we have to have a very minimal solution for adding that piece on because basically all we need to do is bring their stuff and convert it. Once we've converted that new integration into our format, everything else stays the same. It really is like a hook that we can add in at any point and say, oh, we need to add this other system we're going to integrate with. Great. Just figure out what the mappings are, map it into our common format and we're off and running. We'll see in probably the next episode a pattern where such thing is actually very applicable. With the Rosetta Stone, the whole point here is to get to a common language or a common format, a common structure. We will see this in many different areas where we're trying to translate from one thing to another. Particularly like I said, a lot of times it can be data formats and things like that, but there may be some sort of a processing that we need to do from these disparate sources. For example, if we're trying to do an apples to apples comparison of different foreign currencies, then it's easier instead of trying to translate all of the different, let's say dollar to Canadian dollar and whatever that translates into, is translate everything into one common denominator, one common currency in this case, and then do all your calculations there. Instead of having a system that is constantly wheeling and dealing with translating what's a US dollar, what's a Canadian dollar, what's a Mexican dollar, what's a euro, what's the value for all of those, instead you just convert everything to, typically what happens is everything gets converted to US dollars and then you do all your calculations based on US dollars. Then if you have to output it and display it in what is that in rupees, then you do so. At that point then you do it. It allows you to minimize the specialization to only be the translation. Once you translate, then you're off and running. A lot of times it's just the translation in because anybody that's going to integrate with us, we just say, this is what the output is. So they can do all of their, that works on them at that point. They can take that XML file, that fixed length file, whatever it is we kick out, and then they can work with that. They can do their own translations into their systems, whether they need all the information or not really at that point is not, it's not our problem. It's not our concern because we've just made it all available and they can deal with it. And actually we can even do that on the initial integration is that we can say, hey, this is the format we want. So you need to go ahead and build it in. So at that point, our Rosetta Stone approach actually means that we just set it up. We just say, this is the common language and we allow the integrators to be the ones that do the work basically. They are the ones that then are going to have to translate into and out of what our format is. So that's it. It's actually a pretty simple pattern and it really does come down to just making sure you have a common format and then you have a well-defined set of inputs and outputs. You see this a lot in APIs and similar things. So there's a lot of examples out there that you can work with to see how it's been done. Like I said, once you get into the mapping side of it, there's another pattern we're going to talk about, but it becomes almost like a very rote kind of approach to do it. It should not be that complicated. Sometimes you've got data types that can be a little bit of a pain, but generally speaking, it's just a, okay, I take column A is actually column D. This value maps to that value and you run through all the values and then you're done. And that being said, I think now we've run through our little pattern and we can be done with this episode. So as always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor 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. One more thing before you go. Develop-a-Noor Podcasts and Cite are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernoor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.