All right so let's try to summarize the things that we've learned about Memento Design Patterns so essentially
we saw that mementos are typically used to roll back the state of a system so you get this little token
and there isn't much you can really do with a token but you can use it to return the system back to
a particular state.
Now it's typically a memento doesn't have any functions of its own it doesn't allow the manipulation
of its internal state or typically at least that's what typically happens so and the mentor doesn't
allow you to go back into the mento and then modify some of its internal fields because that would allow
you to subsequently restore the system to an invalid state or to a state in which the system quite simply
never was in the first place.
Now if you do decide to store every single memento generated by a system and you agree that every single
part of the API of something like for example a bank account actually generates a memento and you store
those mementos then what you can do as a consequence is you can easily implement undo and read the functionality
because you've essentially saved the entire timeline you say every single state that the system was
ever in so you can walk those states forwards and backwards and allow the user to do undo and redo of
course.
All this is hinged on an assumption that the amount of memory that's required for storing the state
of a system is relatively low that it's a relatively simple process to actually restore the system to
a particular state.
Now if your system has lots of state if you are keeping For example I know you're keeping photographs
of your users and the user changes a photograph and you want to store the previous photograph which
is it could be large.
Who knows then it doesn't make so much sense to use the memento especially in this context of undo and
redo because that would simply take up too much memory.