I’m so surprised to see the difference in the Exercise and the Implementation of the memento pattern. This really doesn’t seem right. I haven’t continue the rest of the course yet; however, I wanted to sure this here:
The exercise said to make a method on the Editor class to then say editor.undo()
I was surprised as well, and would be glad if Mosh could elaborate on that.
I thought that the calls to History should have been encapsulated inside functions like Undo() or Redo() in the Editor class. I don’t think the Main class should be aware of the History class. Am I wrong? @Mosh
Heyhey! I also hope that Mosh can clarify. The way he’s implemented also you’ll notice that he didn’t add the last state change to history, so when he restored, he got “b”, because “c” was not manually added. But in the GOF pattern, it doesn’t seem like originator interacts with history at all and it does make sense for the Document to keep track of state in my opinion. I hope @Mosh reads our comments and clarifies for us.
When I saw this pattern I also asked myself the same question. If it wasn’t better to encapsulate the undo in the Editor class, I think it’s better to hide the implementation of the history and put it inside the Editor, or it does violate some principle?, the other thing that caught my attention is why he doesn’t save the state of “c” after setting the content in the object Editor.
I’m also curious about not saving the state after “c”. Any editor normally would.
Also, if you did save the state after “c”, pop() would return the last state, which is also the current state. So the state wouldn’t change until you call pop() again.
It seems like it should remove the last item and then return the item before it. But then you would want to call it something other than pop()?