Philosophy of createState() in Originator class in Memento Pattern

Design Patterns
1

Hello Guys. I’ve question about the philosophy of createState() in Originator class in Memento Pattern.

Mosh said:

now that Editor(Originator) class no longer stores EditorState(Memento) objects internally, we should give it two new methods; createState() and restoreState().

The createState() method stores the current state of the Editor inside a State object and returns it. So we call this method and say, “Hey, save your current state and give it to me”, we’ll get an EditorState object.

I’m confused. Because when I was trying to implement the Originator (Editor) class that stores a list of EditorState internally ,I still needed to have this createState() method.

my class:

public class MyEditor2 {

    private String content;
    private String title;

    //stores a list of EditorState internally
    private List<EditorState> previousStates;

    public MyEditor2() {

        previousStates = new ArrayList<>();
    }

    public void push() {
        previousStates.add(createState());
    }

    // need to have it.
    private EditorState createState() {
        return new EditorState(content, title);
    }

    public void pop() {

        int lastIndex = previousStates.size() - 1;

        this.content = previousStates.get(lastIndex).getContent();
        this.title = previousStates.get(lastIndex).getTitle();

        previousStates.remove(lastIndex);
    }

    public void setContent(String content) {

        this.content = content;
    }

    public void setTitle(String title) {

        this.title = title;
    }

    public String getContent() {
        return content;
    }

    public String getTitle() {
        return title;
    }

What is the reason for using and creating this method? in both case ( stores EditorState(Memento) objects internally and not storing EditorState(Memento) objects internally), I had to implement that method.

2

Mosh was talking about the Single Responsibility Principle (SRP) and how the implementation that stores the current state and the history directly in the Editor class is violating that principle. You can definitely just store the historical states directly in there, but you will be violating the SRP and it would make sense to have the createState method to make that simpler. He was merely talking about APIs between the different objects involved in the pattern - not implementation details about the specific way you could implement the Editor class. It is also possible to keep separate lists of every piece of historical state and then you would not need an EditorState class at all. That seems worse to me, but you could do it. The point is that there is no absolute need for a createState method if you are storing state locally.

Why does the Editor class need createState and restore methods after history management is delegated to another object? Because the Editor is the only object that knows the current state so it can create the historical record (createState) and it is the interface for updating the current state (restore). That (IMO) is the real philosophy here - just trying to abide by the SRP.