Хранитель - паттерн поведения объектов, сохраняющий состояния. Известен также под именем Token (лексема).
Но обычно объекты инкапсулируют все свое состояние или хотя бы его часть, делая его недоступным для других объектов, так что сохранить состояние извне невозможно. Раскрытие же состояния явилось бы нарушением принципа инкапсуляции и поставило бы под угрозу надежность и расширяемость приложения.
Система разрешения ограничений - хорошо известный способ поддержания связанности между объектами. Ее функции могут выполняться объектом класса ConstraintSolver, который регистрирует вновь создаваемые соединения и генерирует описывающие их математические уравнения. А когда пользователь каким-то образом модифицирует диаграмму, объект решает эти уравнения. Результаты вычислений объект ConstraintSolver использует для перерисовки графики так, чтобы были сохранены все соединения.
Поддержка отката операций в приложениях не так проста, как может показаться на первый взгляд. Очевидный способ откатить операцию перемещения - это сохранить расстояние между старым и новым положением, а затем переместить объект на такое же расстояние назад. Однако при этом не гарантируется, что все объекты окажутся там же, где находились. Предположим, что в способе расположения соединительной линии есть некоторая свобода. Тогда, переместив прямоугольник на прежнее место, мы можем не добиться желаемого эффекта:
- как видно, может легко измениться положение соединительной линии (как пример).
Открытого интерфейса ConstraintSolver иногда не хватает для точного отката всех изменений смежных объектов. Механизм отката должен работать в тесном взаимодействии с ConstraintSolver для восстановления предыдущего состояния, но необходимо также позаботиться о том, чтобы внутренние детали ConstraintSolver не были доступны этому механизму.
Паттерн хранитель поможет решить данную проблему. Хранитель — это объект, в котором сохраняется внутреннее состояния другого объекта - хозяина хранителя. Для работы механизма отката нужно, чтобы хозяин предоставил хранитель, когда возникнет необходимость записать контрольную точку состояния хозяина. Только хозяину разрешено помещать в хранитель информацию и извлекать ее оттуда, для других объектов хранитель непрозрачен.
В примере графического редактора, который обсуждался выше, в роли хозяина может выступать объект ConstraintSolver. Процесс отката характеризуется такой последовательностью событий:
- Редактор запрашивает хранитель у объекта ConstraintSolver в процессе выполнения операции перемещения.
- ConstraintSolver создает и возвращает хранитель, в данном случае экземпляр класса SolverState. Хранитель SolverState содержит структуры данных, описывающие текущее состояние внутренних уравнений и переменных ConstraintSolver.
- Позже, когда пользователь отменяет операцию перемещения, редактор возвращает SolverState объекту ConstraintSolver.
- Основываясь на информации, которая хранится в объекте SolverState, ConstraintSolver изменяет свои внутренние структуры, возвращая уравнения и переменные в первоначальное состояние.
Такая организация позволяет объекту ConstraintSolver «знакомить» другие объекты с информацией, которая ему необходима для возврата в предыдущее состояние, не раскрывая в то же время свою структуру и представление.
Признаки применения, использования паттерна Хранитель (Memento)
Используйте
паттерн хранитель, когда:
- Необходимо сохранить мгновенный снимок состояния объекта (или его части), чтобы впоследствии объект можно было восстановить в том же состоянии.
- Прямое получение этого состояния раскрывает детали реализации и нарушает инкапсуляцию объекта.
Решение
Участники паттерна Хранитель (Memento)
- Memento (SolverState) – хранитель.
Сохраняет внутреннее состояние объекта Originator. Объем сохраняемой информации может быть различным и определяется потребностями хозяина.
Запрещает доступ всем другим объектам, кроме хозяина. По существу, у хранителей есть два интерфейса. «Посыльный» CareTaker «видит» лишь «узкий» интерфейс хранителя - он может только передавать хранителя другим объектам. Напротив, хозяину доступен «широкий» интерфейс, который обеспечивает доступ ко всем данным, необходимым для восстановления в прежнем состоянии. Идеальный вариант - когда только хозяину, создавшему хранитель, открыт доступ к внутреннему состоянию последнего.
- Originator (ConstraintSolver) – хозяин.
Создает хранитель, содержащего снимок текущего внутреннего состояния.
Использует хранитель для восстановления внутреннего состояния.
- CareTaker (механизм отката) – посыльный.
Отвечает за сохранение хранителя.
Не производит никаких операций над хранителем и не исследует его внутреннее содержимое.
Схема использования паттерна Хранитель (Memento)
Посыльный (
CareTaker) запрашивает хранитель у хозяина, некоторое время держит его
у себя, а затем возвращает хозяину, как видно на представленной диаграмме взаимодействий:
Иногда этого возвращения не происходит, так как последнему не всегда нужно восстанавливать прежнее состояние.
Хранители пассивны. Только хозяин, создавший хранитель, имеет доступ к информации о состоянии.
Вопросы, касающиеся реализации паттерна Хранитель (Memento)
При реализации
паттерна хранитель следует иметь в виду:
- Языковую поддержку.
У хранителей есть 2 интерфейса: «широкий» для хозяев и «узкий» для всех остальных объектов. В идеале язык реализации должен поддерживать два уровня статического контроля доступа. В Java это возможно, если сделать хранителя внутренним классом хозяина, а в C++ для этого потребуется объявить хозяина другом хранителя. Далее в любом случае «широкий» интерфейс хранителя делается закрытым (с помощью ключевого слова private), а открытым (public) остается только «узкий» интерфейс. В случае Java хозяин все же получит доступ к широкому интерфейсу, т.к. весь хранитель, оформленный в виде внутреннего класса, будет ему доступен, как и любой другой объявленный в нем член, в случае C++ доступ будет обеспечен явно, т.к. хозяин будет «другом» хранителя. Т.е. в случае 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
() { /* ... */
return res;
}
}
/* Методы, интерфейс хозяина
*/
public Memento CreateMemento() {
Memento res = null;
/* .. */
return res;
}
public void SetMemento(Memento mem) { /* ... */ }
}
}
В случае 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 {
}
- Сохранение инкрементых изменений.
Если хранители создаются и возвращаются своему хозяину в предсказуемой последовательности, то хранитель может сохранить лишь изменения во внутреннем состоянии хозяина.
Например, допускающие отмену команды в списке истории могут пользоваться хранителями для восстановления первоначального состояния (см. паттерн команда). Список истории предназначен только для отмены и повтора команд. Это означает, что хранители могут работать лишь с изменениями, сделанными командой, а не с полным состоянием объекта.
В примере из раздела «Мотивация» объект, отменяющий ограничения, может содержать только такие внутренние структуры, которые изменяются с целью сохранить линию, соединяющую прямоугольники, а не абсолютные позиции всех объектов.
Результаты
Реализация паттерна-хранитель нам дает:
- Сохранение границ инкапсуляции.
Хранитель позволяет избежать раскрытия информации, которой должен распоряжаться только хозяин, но которую тем не менее необходимо хранить вне последнего. Этот паттерн экранирует объекты от потенциально сложного внутреннего устройства хозяина, не изменяя границы инкапсуляции.
- Упрощение структуры хозяина.
При других вариантах дизайна, направленного на сохранение границ инкапсуляции, хозяин хранит внутри себя версии внутреннего состояния, которое запрашивали клиенты. Таким образом, вся ответственность за управление памятью лежит на хозяине. При перекладывании заботы о запрошенном состоянии на клиентов упрощается структура хозяина, а клиентам дается возможность не информировать хозяина о том, что они закончили работу.
- Значительные издержки при использовании хранителей.
С хранителями могут быть связаны заметные издержки, если хозяин должен копировать большой объем информации для занесения в память хранителя или если клиенты создают и возвращают хранителей достаточно часто. Если плата за инкапсуляцию и восстановление состояния хозяина велика, то этот паттерн не всегда подходит.
Недостатки же здесь следующие:
- Определение «узкого» и «широкого» интерфейсов.
В некоторых языках сложно гарантировать, что только хозяин имеет доступ к состоянию хранителя.
- Скрытая плата за содержание хранителя.
Посыльный отвечает за удаление хранителя, однако не располагает информацией о том, какой объем информации о состоянии скрыт в нем. Поэтому нетребовательный к ресурсам посыльный может расходовать очень много памяти при работе с хранителем.
Пример
Представим, что в нашей системе клиенты имеют возможность сделать заказ на некоторый продукт. Выбирается продукт, заполняется форма заказа и далее заказ сохраняется. При этом до того момента как заказ возьмут на исполнение, клиент может редактировать некоторые его параметры.
И вот для большего удоства требуется возможность, чтобы клиент мог «откатывать» свои сделанные изменения в заказе до предыдущего состояния (для простоты – только на 1 уровень назад).
Хороший случай для применения паттерна-хранитель. В качестве
Orinator-а у нас будет выступать сама форма заказа (
OrderForm), которая в своем составе будет определять класс
OrderState (
Memento) хранения только тех параметров заказа, которые клиент вправе изменить:
OrderForm.
Обратите внимание на то что класс OrderState (Memento) объявлен как внутренний в OrderForm. Это в соответствии с тем, что доступ к внутренним элементам хранителя был только у хозяина (Originator-а).
Соотвественно, когда заказ обновляется, вызывается метод UpdateOrder, создающий новый хранитель OrderState со старыми данными. Когда же пользователь решает отменить сделанные изменения – метод RollbackChanges() возвращает из хранителя это предыдущее состояние.
Известные применения паттерна Хранитель (Memento)
Пример раздела «
Мотивация» был основан на поддержке связанности в каркасе
Unidraw с помощью класса
CSolver.
В библиотеке
QOCA для разрешения ограничений в
хранителях содержится информация об изменениях. Клиент может получить хранитель, характеризующий текущее решение системы ограничений. В хранителе находятся только те переменные ограничений, которые были преобразованы со времени последнего решения. Обычно при каждом новом решении изменяется лишь небольшое подмножество переменных Solver. Но этого достаточно, чтобы вернуть Solver к предыдущему решению; для отката к более ранним решениям необходимо иметь все промежуточные хранители. Поэтому передавать хранители в произвольном порядке нельзя. QOCA использует механизм ведения истории для возврата к прежним решениям.
Родственные паттерны
Команда: команды помещают информацию о состоянии, необходимую для отмены выполненных действий, в
хранители.