1. Редактор запрашивает хранитель у объекта ConstraintSolver в процессе выполнения операции перемещения.
2. ConstraintSolver создает и возвращает хранитель, в данном случае экземпляр класса SolverState. Хранитель SolverState содержит структуры данных, описывающие текущее состояние внутренних уравнений и переменных ConstraintSolver.
3. Позже, когда пользователь отменяет операцию перемещения, редактор возвращает SolverState объекту ConstraintSolver.
4. Основываясь на информации, которая хранится в объекте SolverState, ConstraintSolver изменяет свои внутренние структуры, возвращая уравнения и переменные в первоначальное состояние.

1. Необходимо сохранить мгновенный снимок состояния объекта (или его части), чтобы впоследствии объект можно было восстановить в том же состоянии.
2. Прямое получение этого состояния раскрывает детали реализации и нарушает инкапсуляцию объекта.

Решение

Участники паттерна Хранитель (Memento)

1. Memento (SolverState) – хранитель.
   Сохраняет внутреннее состояние объекта Originator. Объем сохраняемой информации может быть различным и определяется потребностями хозяина.
   Запрещает доступ всем другим объектам, кроме хозяина. По существу, у хранителей есть два интерфейса. «Посыльный» CareTaker «видит» лишь «узкий» интерфейс хранителя - он может только передавать хранителя другим объектам. Напротив, хозяину доступен «широкий» интерфейс, который обеспечивает доступ ко всем данным, необходимым для восстановления в прежнем состоянии. Идеальный вариант - когда только хозяину, создавшему хранитель, открыт доступ к внутреннему состоянию последнего.
2. Originator (ConstraintSolver) – хозяин.
   Создает хранитель, содержащего снимок текущего внутреннего состояния.
   Использует хранитель для восстановления внутреннего состояния.
3. CareTaker (механизм отката) – посыльный.
   Отвечает за сохранение хранителя.
   Не производит никаких операций над хранителем и не исследует его внутреннее содержимое.

у себя, а затем возвращает хозяину, как видно на представленной диаграмме взаимодействий:

Хранители пассивны. Только хозяин, создавший хранитель, имеет доступ к информации о состоянии.

1. Языковую поддержку.
   У хранителей есть 2 интерфейса: «широкий» для хозяев и «узкий» для всех остальных объектов. В идеале язык реализации должен поддерживать два уровня статического контроля доступа. В Java это возможно, если сделать хранителя внутренним классом хозяина, а в C++ для этого потребуется объявить хозяина другом хранителя. Далее в любом случае «широкий» интерфейс хранителя делается закрытым (с помощью ключевого слова private), а открытым (public) остается только «узкий» интерфейс. В случае Java хозяин все же получит доступ к широкому интерфейсу, т.к. весь хранитель, оформленный в виде внутреннего класса, будет ему доступен, как и любой другой объявленный в нем член, в случае C++ доступ будет обеспечен явно, т.к. хозяин будет «другом» хранителя. Т.е. в случае Java получим:
    хранитель в виде внутреннего класса [java]  ссылка
   

   package memento;
    
   public class Originator {
   	/**
   	 * Хранитель, определенный в виде
   	 * внутреннего члена класса Originator-а
   	 */
   	public class Memento {
   		/* "Узкий" открытый интерфейс хранителя,
   		 * доступный всем
   		 */
   		public void CompressMementoState() {
   			/* ..Оптимизируем размер, занимаемым хранителем.. */
   		}
   		public int GetMementoSize() {
   			int res = 0;
   			/* ..Вычисляем размер, занимаемый хранителем.. */
   			return res;
   		}
    
   		/* "Широкий" закрытый интерфейс хранителя,
   		 * доступный только хозяину (Originator-у в данном случае)
   		 */
   		private Memento() {
   			/* ... */
   		}
    
   		private void SetState(State state) {
   			/* ... */
   		}
    
   		private State GetState() {
   			State res = null;
   			/* ... */
   			return res;
   		}
   	}
    
   	/* Методы, интерфейс хозяина
   	 */
   	public Memento CreateMemento() {
   		Memento res = null;
   		/* .. */
   		return res;
   	} 
    
   	public void SetMemento(Memento mem) { /* ... */ }
   }
    
   class State {
    
   }
    

   package memento; public class Originator { /** * Хранитель, определенный в виде * внутреннего члена класса Originator-а */ public class Memento { /* "Узкий" открытый интерфейс хранителя, * доступный всем */ public void CompressMementoState() { /* ..Оптимизируем размер, занимаемым хранителем.. */ } public int GetMementoSize() { int res = 0; /* ..Вычисляем размер, занимаемый хранителем.. */ return res; } /* "Широкий" закрытый интерфейс хранителя, * доступный только хозяину (Originator-у в данном случае) */ private Memento() { /* ... */ } private void SetState(State state) { /* ... */ } private State GetState() { State res = null; /* ... */ return res; } } /* Методы, интерфейс хозяина */ public Memento CreateMemento() { Memento res = null; /* .. */ return res; } public void SetMemento(Memento mem) { /* ... */ } } class State { }
   
   В случае C++:
    хранитель в виде дружеского класса [C++]  ссылка
   

   package memento;
    
   class Originator2 {
   	public:
   	Memento* CreateMemento();
   	void SetMemento(const Memento*);
   	// ...
   	private:
   	State* _state; // внутренние структуры данных
   	// ...
   };
   class Memento {
   	public:
   	// узкий открытый интерфейс
   	virtual ~Memento();
   	private:
   	// закрытые члены доступны только хозяину Originator
   	friend class Originator;
   	Memento();
   	void SetState(State*);
   	State* GetState() ;
   	// ...
   	private:
   	State* state;
   	// ...
   };
    
   class State {
    
   }

   package memento; class Originator2 { public: Memento* CreateMemento(); void SetMemento(const Memento*); // ... private: State* _state; // внутренние структуры данных // ... }; class Memento { public: // узкий открытый интерфейс virtual ~Memento(); private: // закрытые члены доступны только хозяину Originator friend class Originator; Memento(); void SetState(State*); State* GetState() ; // ... private: State* state; // ... }; class State { }
   
2. Сохранение инкрементых изменений.
   Если хранители создаются и возвращаются своему хозяину в предсказуемой последовательности, то хранитель может сохранить лишь изменения во внутреннем состоянии хозяина.
   Например, допускающие отмену команды в списке истории могут пользоваться хранителями для восстановления первоначального состояния (см. паттерн команда). Список истории предназначен только для отмены и повтора команд. Это означает, что хранители могут работать лишь с изменениями, сделанными командой, а не с полным состоянием объекта.
   В примере из раздела «Мотивация» объект, отменяющий ограничения, может содержать только такие внутренние структуры, которые изменяются с целью сохранить линию, соединяющую прямоугольники, а не абсолютные позиции всех объектов.

1. Сохранение границ инкапсуляции.
   Хранитель позволяет избежать раскрытия информации, которой должен распоряжаться только хозяин, но которую тем не менее необходимо хранить вне последнего. Этот паттерн экранирует объекты от потенциально сложного внутреннего устройства хозяина, не изменяя границы инкапсуляции.
2. Упрощение структуры хозяина.
   При других вариантах дизайна, направленного на сохранение границ инкапсуляции, хозяин хранит внутри себя версии внутреннего состояния, которое запрашивали клиенты. Таким образом, вся ответственность за управление памятью лежит на хозяине. При перекладывании заботы о запрошенном состоянии на клиентов упрощается структура хозяина, а клиентам дается возможность не информировать хозяина о том, что они закончили работу.
3. Значительные издержки при использовании хранителей.
   С хранителями могут быть связаны заметные издержки, если хозяин должен копировать большой объем информации для занесения в память хранителя или если клиенты создают и возвращают хранителей достаточно часто. Если плата за инкапсуляцию и восстановление состояния хозяина велика, то этот паттерн не всегда подходит.

1. Определение «узкого» и «широкого» интерфейсов.
   В некоторых языках сложно гарантировать, что только хозяин имеет доступ к состоянию хранителя.
2. Скрытая плата за содержание хранителя.
   Посыльный отвечает за удаление хранителя, однако не располагает информацией о том, какой объем информации о состоянии скрыт в нем. Поэтому нетребовательный к ресурсам посыльный может расходовать очень много памяти при работе с хранителем.