Memento & Command Patterns

[00:00:00]
>> Maximiliano Firtman: Another one, and we will implement this one later. Memento, that's a nice name. Have you seen the movie, Memento? There is a relationship with the movie. The problem to solve is we wanna capture and externalize an object's internal state so that it can be restored later, without violating encapsulation.

[00:00:21]
And you say, why memento? Memento has to do with memory, right? So it has to do with having memory of the current state of the app. So we create an object that stores the state of the original object and provide method to save and restore the state. I mean, it sounds like blah, blah, but it's actually pretty simple.

[00:00:40]
And one of the great use cases of this is Undo/Redo functionality. So we can create an undo system, so Ctrl + C or Command + C, for example, on your system, and go back to your previous state. And we will implement this later, and you will see how we see is to implement undo when you use the pattern.

[00:01:05]
Without the pattern, it's actually so complicated. It's actually how to go back to the previous state, okay? Well, saving a game, an app session. So I can restore that when I go back. This is pretty useful for web apps. So when you go back to the web app, it's the same situation where you left yesterday.

[00:01:29]
Or time-travel debugging, for debugging, this is important. So there was a problem, but now the user continues changing the web app. So how can I go back? How can I time-travel back to the moment where the exception happened so I can see what was the problem at that moment, okay?

[00:01:50]
So we will implement that. So I will take more time to explain this later, it's not a big deal. We have typically a history manager that has an array. And we push, actually, we take treated this as a pile, so we push and we pop, that's all. The state, and what's the state?

[00:02:10]
Anything that defines your app. It can be all the information on the screen, the scroll position, whatever is typed in every input form element and so on. We will see this in action in a second. And the last one before actually implementing this in code, that is the funnest part here, is command.

[00:02:37]
What's the idea of command? We wanna avoid hard-wiring a request from its invoker. So I have a button on click, you put an on click handler, and you say, when that button is pressed, I need to save data in a database. So on click equals to function, and you start writing your SQL query, so index DB-API usage to store the data.

[00:03:04]
But you are hard-wiring there the invoker with the process. So later, for example, if you also wanna save with Ctrl + S, it's already wired into the on click handler, so it's difficult. Then you listen for the keyboard events and you call the click event handler, so it's a mess.

[00:03:28]
So we wanna avoid that, so for that we create an object that is used to encapsulate all the information needed to perform an action or trigger an event in your system. it's like you say, I wanna save, and you talk to a command executor option, hey, I need to save and he knows how to save.

[00:03:50]
So you don't write the code to save in the click handler, okay? Make sense? So managing the action of your app is one use case, add, delete, print, save. Everything that happens in your app, you don't hardwire that in the event handlers.