Э. Гамма Р. Хелм Р. Джонсон Дж. Влиссидес

Вид материала

Документы

Содержание Паттерн Memento Известные применения Паттерн Memento Родственные паттерны Паттерн Observer Известен также под именем Паттерны поведения Паттерны поведения Паттерн Observer Пример кода Известные применения Родственные паттерны Паттерн State Q Подклассы ConcreteState

Подобный материал:

• Прослушивание цикла лекций; проведение лабораторных занятий по интерпретации результатов, 23.31kb.
• Космическое рентгеновское и гамма-излучение, 1234.69kb.
• Название эксперимента, 62.39kb.
• Оздоровительный комплекс «Гамма» 10 Отель «Гамма» 11 Пансионат «Светлана» 12 Экскурсия, 2786.29kb.
• Французский реечный потолок реечные потолки, 207.48kb.
• План выставки при IV международной конференции «металлургия-интехэко-2011» холл конференц-зала, 60.11kb.
• Исследование cnd- вещества, методом отражения рентгеновского и гамма – излучения, 75.73kb.
• Эффект Мёссбауэра 2ч, 233.13kb.
• Список художественной литературы для фс-3, фж-3, 15.57kb.
• Поэзия Марины Цветаевой Лакофф Дж., Джонсон М. Метафоры, которыми мы живем литература, 21.08kb.

^ Паттерн Memento

а сохранение инкрементых изменений. Если хранители создаются и возвраща­ются своему хозяину в предсказуемой последовательности, то хранитель

может сохранить лишь изменения во внутреннем состоянии хозяина. Например, допускающие отмену команды в списке истории могут пользо­ваться хранителями для восстановления первоначального состояния (см. описание паттерна команда). Список истории предназначен только для от­мены и повтора команд. Это означает, что хранители могут работать лишь с изменениями, сделанными командой, а не с полным состоянием объекта. В примере из раздела «Мотивация» объект, отменяющий ограничения, мо­жет содержать только такие внутренние структуры, которые изменяются с целью сохранить линию, соединяющую прямоугольники, а не абсолютные позиции всех объектов.

Пример кода

Приведенный пример кода на языке C++ иллюстрирует рассмотренный выше пример класса ConstraintSolver для разрешения ограничений. Мы используем

объекты MoveCommand (см. паттерн команда) для выполнения и отмены перено­са графического объекта из одного места в другое. Графический редактор вызыва­ет операцию Execute объекта-команды, чтобы переместить объект, и команду Unexecute, чтобы отменить перемещение. В команде хранятся координаты места на­значения, величина перемещения и экземпляр класса ConstraintSolverMemento — хранителя, содержащего состояние объекта ConstraintSolver:

class Graphic;

// базовый класс графических объектов

class MoveCoitimand { public:

MoveCommand (Graphic* target, const Point& delta) ;

void Execute ( ) ;

void Unexecute ( ) ; private:

ConstraintSolverMemento* _state ;

Point _delta;

Graphic* _target;

};

Ограничения связанности устанавливаются классом ConstraintSolver. Его основная функция-член, называемая Solve, отменяет ограничения, реги­стрируемые операцией AddConstraint. Для поддержки отмены действий со­стояние объекта ConstraintSolver можно разместить в экземпляре класса ConstraintSolverMemento с помощью операции CreateMemento. В преды­дущее состояние объект ConstraintSolver возвращается посредством операции SetMemento. ConstraintSolver является примером паттерна одиночка:

class ConstraintSolver { public:

static ConstraintSolver* Instanced;

void Solve();

Паттерны поведения


void AddConstraint(

Graphic* startConnection, Graphic* endConnection

);

void RemoveConstraint(

Graphic* startConnection, Graphic* endConnection ) ;

ConstraintSolverMemento* CreateMemento(); void SetMemento(ConstraintSolverMemento*); private:

// нетривиальное состояние и операции // для поддержки семантики связанности

class ConstraintSolverMemento { public:

virtual -ConstraintSolverMemento(); private:

friend class ConstraintSolver;

ConstraintSolverMemento();

// закрытое состояние Solver

j

С такими интерфейсами мы можем реализовать функции-члены Execute и Unexecute в классе MoveCommand следующим образом:

void MoveCommand::Execute () {

ConstraintSolver* solver = ConstraintSolver::Instance(); _state = solver->CreateMemento(); // создание хранителя _target->Move(_delta); solver->Solve() ;

void MoveCommand::Unexecute () {

ConstraintSolver* solver = ConstraintSolver::Instance(); _target->Move(-_delta) ;

solver->SetMemento(_state) ; // восстановление состояния хозяина solver->Solve(};

Execute запрашивает хранитель ConstraintSolverMemento перед началом

перемещения графического объекта. Unexecute возвращает объект на прежнее место, восстанавливает состояние Solver и обращается к последнему с целью от­менить ограничения.

^ Известные применения

Предыдущий пример основан на поддержке связанности в каркасе Unidraw с помощью класса C Solver [VL90].

В коллекциях языка Dylan [App92] для итерации предусмотрен интерфейс, напоминающий паттерн хранитель. Для этих коллекций существует понятие состояния объекта, которое является хранителем, представляющим состояние


^ Паттерн Memento

итерации. Представление текущего состояния каждой коллекции может быть лю­бым, но оно полностью скрыто от клиентов. Решение, используемое в языке Dylan, можно написать на C++ следующим образом:

template class Collection { public:

Collection();

IterationState* CreatelnitialState();

void Next(IterationState*) ;

bool IsDone(const IterationState*) const;

Item Currentltemfconst IterationState*) const;

IterationState* Copy(const IterationState*) const;

void Appendfconst Item&) ; void Remove(const Item&);

Операция CreatelnitialState возвращает инициализированный объект IterationState для коллекции. Операция Next переходит к следующему объек­ту в порядке итерации, по сути дела, она увеличивает на единицу индекс итерации. Операция IsDone возвращает true, если в результате выполнения Next мы оказа­лись за последним элементом коллекции. Операция Cur rent It em разыменовыва­ет объект состояния и возвращает тот элемент коллекции, на который он ссылает­ся. Сору возвращает копию данного объекта состояния. Это имеет смысл, когда необходимо оставить закладку в некотором месте, пройденном во время итерации.

Если есть класс ItemType, то обойти коллекцию, составленную из его экземп­ляров, можно так:¹

class ItemType { public:

void Process () ;

Collection aCollection; IterationState* state;

state = aCollection.CreatelnitialStatef);

while (laCollection.IsDone(state)) {

aCollection.Currentltem(state)->Process()

aCollection.Next(state) ; } delete state;

Отметим, что в нашем примере объект состояния удаляется по завершении итерации. Но оператор delete не будет вызван, если Processltem возбудит исключение, поэтому в памяти остается му­сор. Это проблема в языке C++, но не в Dylan, где есть сборщик мусора. Решение проблемы обсужда­ется на стр. 258.


Паттерны поведения

У интерфейса итерации, основанного на паттерне хранитель, есть два преиму­щества:

а с одной коллекцией может быть связано несколько активных состояний (то же самое верно и для паттерна итератор);

а не требуется нарушать инкапсуляцию коллекции для поддержки итерации. Хранитель интерпретируется только самой коллекцией, больше никто к нему доступа не имеет. При других подходах приходится нарушать инкапсуляцию, объявляя классы итераторов друзьями классов коллекций (см. описание пат­терна итератор). В случае с хранителем ситуация противоположная: класс коллекции Collection является другом класса IteratorState.

В библиотеке QOCA для разрешения ограничений в хранителях содержится информация об изменениях. Клиент может получить хранитель, характеризую­щий текущее решение системы ограничений. В хранителе находятся только те переменные ограничений, которые были преобразованы со времени последнего решения. Обычно при каждом новом решении изменяется лишь небольшое под­множество переменных Solver. Но этого достаточно, чтобы вернуть Solver к предыдущему решению; для отката к более ранним решениям необходимо иметь все промежуточные хранители. Поэтому передавать хранители в произвольном по­рядке нельзя. QOCA использует механизм ведения истории для возврата к преж­ним решениям.

^ Родственные паттерны

Команда: команды помещают информацию о состоянии, необходимую для от­мены выполненных действий, в хранители.

Итератор: хранители можно использовать для итераций, как было показано выше.

^ Паттерн Observer

Название и классификация паттерна

Наблюдатель - паттерн поведения объектов.

Назначение

Определяет зависимость типа «один ко многим» между объектами таким об­разом, что при изменении состояния одного объекта все зависящие от него опове­щаются об этом и автоматически обновляются.

^ Известен также под именем

Dependents (подчиненные), Publish-Subscribe (издатель-подписчик).

Мотивация

В результате разбиения системы на множество совместно работающих классов появляется необходимость поддерживать согласованное состояние взаимосвязанных


Паттерн Observer

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

Например, во многих библиотеках для построения графических интерфейсов пользователя презентационные аспекты интерфейса отделены от данных прило­жения [КР88, LVC89, Р+88, WGM88]. С классами, описывающими данные и их представление, можно работать автономно. Электронная таблица и диаграмма не имеют информации друг о друге, поэтому вы вправе использовать их по отдельнос­ти. Но ведут они себя так, как будто «знают» друг о друге. Когда пользователь ра­ботает с таблицей, все изменения немедленно отражаются на диаграмме, и наобо-р о т .



При таком поведении подразумевается, что и электронная таблица, и диаграм­ма зависят от данных объекта и поэтому должны уведомляться о любых измене­ниях в его состоянии. И нет никаких причин, ограничивающих количество зави­симых объектов; для работы с одними и теми же данными может существовать любое число пользовательских интерфейсов.

Паттерн наблюдатель описывает, как устанавливать такие отношения. Клю­чевыми объектами в нем являются субъект и наблюдатель. У субъекта может быть сколько угодно зависимых от него наблюдателей. Все наблюдатели уведом­ляются об изменениях в состоянии субъекта. Получив уведомление, наблюдатель опрашивает субъекта, чтобы синхронизировать с ним свое состояние.

Такого рода взаимодействие часто называется отношением издатель-подпис­чик. Субъект издает или публикует уведомления и рассылает их, даже не имея ин­формации о том, какие объекты являются подписчиками. На получение уведомле­ний может подписаться неограниченное количество наблюдателей.

Применимость

Используйте паттерн наблюдатель в следующих ситуациях:

а когда у абстракции есть два аспекта, один из которых зависит от другого. Инкапсуляции этих аспектов в разные объекты позволяют изменять и по­вторно использовать их независимо;

^ Паттерны поведения

а когда при модификации одного объекта требуется изменить другие и вы не

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

уведомляемых объектах. Другими словами, вы не хотите, чтобы объекты

были тесно связаны между собой.

Структура




Участники

a Subject - субъект:

- располагает информацией о своих наблюдателях. За субъектом может
«следить» любое число наблюдателей;

- предоставляет интерфейс для присоединения и отделения наблюдателей;
a Observer - наблюдатель:

- определяет интерфейс обновления для объектов, которые должны быть
уведомлены об изменении субъекта;

a ConcreteSubject - конкретный субъект:

- сохраняет состояние, представляющее интерес для конкретного наблюда­
теля ConcreteObserver;

- посылает информацию своим наблюдателям, когда происходит изменение;
a ConcreteObserver - конкретный наблюдатель:

- хранит ссылку на объект класса ConcreteSubj ect;

• сохраняет данные, которые должны быть согласованы с данными субъекта;
  

• реализует интерфейс обновления, определенный в классе Observer, что­
  бы поддерживать согласованность с субъектом.
  

Отношения

а объект ConcreteSubject уведомляет своих наблюдателей о любом изме­нении, которое могло бы привести к рассогласованности состояний наблю­дателя и субъекта;

а после получения от конкретного субъекта уведомления об изменении объ­ект ConcreteObserver может запросить у субъекта дополнительную


Паттерн Observer

информацию, которую использует для того, чтобы оказаться в состоянии, согласованном с состоянием субъекта.

На диаграмме взаимодействий показаны отношения между субъектом и дву­мя наблюдателями.



Отметим, что объект Observer, который инициирует запрос на изменение, откладывает свое обновление до получения уведомления от субъекта. Опера­ция Notify не всегда вызывается субъектом. Ее может вызвать и наблюдатель, и посторонний объект. В разделе «Реализация» обсуждаются часто встреча­ющиеся варианты.

Результаты

Паттерн наблюдатель позволяет изменять субъекты и наблюдатели незави­симо друг от друга. Субъекты разрешается повторно использовать без участия на­блюдателей, и наоборот. Это дает возможность добавлять новых наблюдателей без модификации субъекта или других наблюдателей.

Рассмотрим некоторые достоинства и недостатки паттерна наблюдатель:

а абстрактная связанность субъекта и наблюдателя. Субъект имеет инфор­мацию лишь о том, что у него есть ряд наблюдателей, каждый из которых подчиняется простому интерфейсу абстрактного класса Observer. Субъ­екту неизвестны конкретные классы наблюдателей. Таким образом, связи между субъектами и наблюдателями носят абстрактный характер и сведе­ны к минимуму.

Поскольку субъект и наблюдатель не являются тесно связанными, то они могут находиться на разных уровнях абстракции системы. Субъект более низкого уровня может уведомлять наблюдателей, находящихся на верхних уровнях, не нарушая иерархии системы. Если бы субъект и наблюдатель представляли собой единое целое, то получающийся объект либо пересе­кал бы границы уровней (нарушая принцип их формирования), либо дол­жен был находиться на каком-то одном уровне (компрометируя абстрак­цию уровня);


^ Паттерны поведения

а поддержка широковещательных коммуникаций. В отличие от обычного за­проса для уведомления, посылаемого субъектом, не нужно задавать опреде­ленного получателя. Уведомление автоматически поступает всем подписав­шимся на него объектам. Субъекту не нужна информация о количестве таких объектов, от него требуется всего лишь уведомить своих наблюдате­лей. Поэтому мы можем в любое время добавлять и удалять наблюдателей. Наблюдатель сам решает, обработать полученное уведомление или игнори­ровать его;

а неожиданные обновления. Поскольку наблюдатели не располагают информа­цией друг о друге, им неизвестно и о том, во что обходится изменение субъек­та. Безобидная, на первый взгляд, операция над субъектом может вызвать целый ряд обновлений наблюдателей и зависящих от них объектов. Более того, нечетко определенные или плохо поддерживаемые критерии зависи­мости могут стать причиной непредвиденных обновлений, отследить кото­рые очень сложно.

Эта проблема усугубляется еще и тем, что простой протокол обновления не содержит никаких сведений о том, что именно изменилось в субъекте. Без дополнительного протокола, помогающего выяснить характер изменений, наблюдатели будут вынуждены проделать сложную работу для косвенного получения такой информации.

Реализация

В этом разделе обсуждаются вопросы, относящиеся к реализации механизма зависимостей:

а отображение субъектов на наблюдателей. С помощью этого простейшего способа субъект может отследить всех наблюдателей, которым он должен по­сылать уведомления, то есть хранить на них явные ссылки. Однако при на­личии большого числа субъектов и всего нескольких наблюдателей это мо­жет оказаться накладно. Один из возможных компромиссов в пользу экономии памяти за счет времени состоит в том, чтобы использовать ассоци­ативный массив (например, хэш-таблицу) для хранения отображения меж­ду субъектами и наблюдателями. Тогда субъект, у которого нет наблюдате­лей, не будет зря расходовать память. С другой стороны, при таком подходе увеличивается время поиска наблюдателей;

а наблюдение более чем за одним субъектом. Иногда наблюдатель может зави­сеть более чем от одного субъекта. Например, у электронной таблицы быва­ет более одного источника данных. В таких случаях необходимо расширить интерфейс Update, чтобы наблюдатель мог «узнать», какой субъект прислал уведомление. Субъект может просто передать себя в качестве параметра операции Update, тем самым сообщая наблюдателю, что именно нужно об­следовать;

а кто инициирует обновление. Чтобы сохранить согласованность, субъект и его наблюдатели полагаются на механизм уведомлений. Но какой именно объект вызывает операцию-Notify для инициирования обновления? Есть два варианта:


Паттерн Observer

• операции класса Sub j ect, изменившие состояние, вызывают Noti f у для
  уведомления об этом изменении. Преимущество такого подхода в том, что
  клиентам не надо помнить о необходимости вызывать операцию Notify
  субъекта. Недостаток же заключается в следующем: при выполнении каж­
  дой из нескольких последовательных операций будут производиться обнов­
  ления, что может стать причиной неэффективной работы программы;
  
• ответственность за своевременный вызов Notify возлагается на клиен­
  та. Преимущество: клиент может отложить инициирование обновления
  до завершения серии изменений, исключив тем самым ненужные проме­
  жуточные обновления. Недостаток: у клиентов появляется дополнитель­
  ная обязанность. Это увеличивает вероятность ошибок, поскольку кли­
  ент может забыть вызвать Notify;
  

а висячие ссылки на удаленные субъекты. Удаление субъекта не должно при­водить к появлению висячих ссылок у наблюдателей. Избежать этого мож­но, например, поручив субъекту уведомлять все свои наблюдатели о своем удалении, чтобы они могли уничтожить хранимые у себя ссылки. В общем случае простое удаление наблюдателей не годится, так как на них могут ссылаться другие объекты и под их наблюдением могут находиться другие субъекты;

а гарантии непротиворечивости состояния субъекта перед отправкой уведом­ления. Важно быть уверенным, что перед вызовом операции Notify состо­яние субъекта непротиворечиво, поскольку в процессе обновления соб­ственного состояния наблюдатели будут опрашивать состояние субъекта. Правило непротиворечивости очень легко нарушить, если операции одного из подклассов класса Subject вызывают унаследованные операции. На­пример, в следующем фрагменте уведомление отправляется, когда состоя­ние субъекта противоречиво:

void MySubject::0peration (int newValue) { В aseClass Subject ::Operation(newValue); // отправить уведомление

_my!nstVar += newValue;

// обновить состояние подкласса (слишком поздно!) }

Избежать этой ловушки можно, отправляя уведомления из шаблонных ме­тодов (см. описание паттерна шаблонный метод) абстрактного класса Subject. Определите примитивную операцию, замещаемую в подклассах, и обратитесь к Notify, используя последнюю операцию в шаблонном мето­де. В таком случае существует гарантия, что состояние объекта непротиво­речиво, если операции Subject замещены в подклассах:

void Text::Cut (TextRange r) {

ReplaceRange(г) ; // переопределена в подклассах Notify () ;

гдд Паттерны поведения

Кстати, всегда желательно фиксировать, какие операции класса Subject инициируют обновления;

а как избежать зависимости протокола обновления от наблюдателя: модели вытягивания и проталкивания. В реализациях паттерна наблюдатель субъ­ект довольно часто транслирует всем подписчикам дополнительную инфор­мацию о характере изменения. Она передается в виде аргумента операции Update, и объем ее меняется в широких диапазонах.

На одном полюсе находится так называемая модель проталкивания (push model), когда субъект посылает наблюдателям детальную информацию об изменении независимо от того, нужно ли им это. На другом - модель вытя­гивания (pull model), когда субъект не посылает ничего, кроме минимально­го уведомления, а наблюдатели запрашивают детали позднее. В модели вытягивания подчеркивается неинформированность субъекта о сво­их наблюдателях, а в модели проталкивания предполагается, что субъект вла­деет определенной информацией о потребностях наблюдателей. В случае применения модели проталкивания степень повторного их использования может снизиться, так как классы Sub j ect предполагают о классах Observer, которые не всегда могут быть верны. С другой стороны, модель вытягивания может оказаться неэффективной, ибо наблюдателям без помощи субъекта необходимо выяснять, что изменилось;

а явное специфицирование представляющих интерес модификаций Эффек­тивность обновления можно повысить, расширив интерфейс регистрации субъекта, то есть предоставив возможность при регистрации наблюдателя указать, какие события его интересуют. Когда событие происходит, субъект информирует лишь тех наблюдателей, которые проявили к нему интерес. Чтобы получать конкретное событие, наблюдатели присоединяются к сво­им субъектам следующим образом:

void Subject: :Attach(Observer* , Aspects interest);

где interest определяет представляющее интерес событие. В момент по­сылки уведомления субъект передает своим наблюдателям изменившийся аспект в виде параметра операции Update. Например:

void Observer::Update(Subject*, Aspects interest);

а инкапсуляция сложной семантики обновления. Если отношения зависимос­ти между субъектами и наблюдателями становятся особенно сложными, то может потребоваться объект, инкапсулирующий эти отношения. Будем на­зывать его ChangeManager (менеджер изменений). Он служит для мини­мизации объема работы, необходимой для того чтобы наблюдатели смогли отразить изменения субъекта. Например, если некоторая операция влечет за собой изменения в нескольких независимых субъектах, то хотелось бы, чтобы наблюдатели уведомлялись после того, как будут модифицированы все субъекты, дабы не ставить в известность одного и того же наблюдателя несколько раз.


^ Паттерн Observer

У класса ChangeManager есть три обязанности:

• строить отображение между субъектом и его наблюдателями и предо­
  ставлять интерфейс для поддержания отображения в актуальном состоя­
  нии. Это освобождает субъектов от необходимости хранить ссылки на
  своих наблюдателей и наоборот;
  
• определять конкретную стратегию обновления;
  
• обновлять всех зависимых наблюдателей по запросу от субъекта.
  

На следующей диаграмме представлена простая реализация паттерна на­блюдатель с использованием менеджера изменений ChangeManager. Име­ется два специализированных менеджера. SimplechangeManager всегда обновляет всех наблюдателей каждого субъекта, a DAGChangeManager обра­батывает направленные ациклические графы зависимостей между субъектами и их наблюдателями. Когда наблюдатель должен «присматривать» за несколь­кими субъектами, предпочтительнее использовать DAGChangeManager. В этом случае изменение сразу двух или более субъектов может привести к избыточ­ным обновлениям. Объект DAGChangeManager гарантирует, что наблюдатель в любом случае получит только одно уведомление. Если обновление одного и того же наблюдателя допускается несколько раз подряд, то вполне достаточ­но объекта SimplechangeManager.



ChangeManager - это пример паттерна посредник. В общем случае есть только один объект ChangeManager, известный всем участникам. Поэтому полезен будет также и паттерн одиночка;

а комбинирование классов Subject и Observer, В библиотеках классов, которые на­писаны на языках, не поддерживающих множественного наследования (на­пример, на Smalltalk), обычно не определяются отдельные классы Subject и Observer. Их интерфейсы комбинируются в одном классе. Это позво­ляет определить объект, выступающий в роли одновременно субъекта


Паттерны поведения

и наблюдателя, без множественного наследования. Так, в Smalltalk интерфей­сы Sub j ect и Observer определены в корневом классе Obj ect и потому до­ступны вообще всем классам.

^ Пример кода

Интерфейс наблюдателя определен в абстрактном классе Observer:

class Subject;

class Observer { public:

virtual -Observer ();

virtual void Update (Subject* theChangedSubject) = 0; protected:

Observer ( ) ,-

};

При такой реализации поддерживается несколько субъектов для одного на­блюдателя. Передача субъекта параметром операции Update позволяет наблюда­телю определить, какой из наблюдаемых им субъектов изменился.

Таким же образом в абстрактном классе Subject определен интерфейс субъекта:

class Subject { public:

virtual -Subject()

virtual void Attach(Observer*);

virtual void Detach(Observer*);

virtual void Notify(); protected:

Subject(); private:

List<0bserver*> *_observers;

void Subject::Attach (Observer* o) {

_observers->Append(o);

void Subject: :Detach (Observer* o) { _observers->Remove(o);

void Subject::Notify () {

Listlterator<0bserver*> i(„observers);

for (i.First (); !i.IsDone() ; i.NextO) { i.Currentltemf)->Update(this);

Паттерн Observer

ClockTimer - это конкретный субъект, который следит за временем суток. Он извещает наблюдателей каждую секунду. Класс ClockTimer предоставляет

интерфейс для получения отдельных компонентов времени: часа, минуты, секун­ды и т.д.:

class ClockTimer : public Subject { public:

ClockTimer() ;

virtual int GetfHour ();

virtual int GetMinute(); virtual int GetSecond (') ;

void Tick() ;

Операция Tick вызывается через одинаковые интервалы внутренним тайме­ром . Тем самым обеспечивается правильный отсчет времени. При этом обновля­ется внутреннее состояние объекта ClockTimer и вызывается операция Noti fy для извещения наблюдателей об изменении:

void ClockTimer::Tick () {

// обновить внутреннее представление о времени

Notify () ;

Теперь мы можем определить класс DigitalClock, который отображает время. Свою графическую функциональность он наследует от класса Widget, предоставля­емого библиотекой для построения пользовательских интерфейсов. Интерфейс на­блюдателя подмешивается к интерфейсу DigitalClock путем наследования от клас­са Observer:

class DigitalClock: public Widget, public Observer { public:

DigitalClock(ClockTimer*);

virtual -DigitalClock();

virtual void Update(Subject*);

// замещает операцию класса Observer

virtual void Draw();

// замещает операцию класса Widget;

// определяет способ изображения часов private:

ClockTimer* _subject;

) /

DigitalClock::DigitalClock (ClockTimer* s) {

Паттерны поведения


subject = s; subject->Attach(this);

DigitalClock::~DigitalClock () {

_subject->Detach(this); }

Прежде чем начнется рисование часов посредством операции Update, будет

проверено, что уведомление получено именно от объекта таймера:

void DigitalClock::Update (Subject* theChangedSubject) { if (theChangedSubject == _subject) { Draw ();

void DigitalClock::Draw () {

// получить новые значения от субъекта

int hour = _subject->GetHour(); int minute = _subject->GetMinute();

// и т.д.

// нарисовать цифровые часы

Аналогично можно определить класс Ana logC lock:

class AnalogClock : public Widget, public Observer { public:

AnalogClock(ClockTimer*);

virtual void Update(Subject*);

virtual void Draw();

'/

Следующий код создает объекты классов AnalogClock и DigitalClock, ко­торые всегда показывают одно и то же время:

ClockTimer* timer = new- ClockTimer;

AnalogClock* analogclock = new AnalogClock ( t imer ) ;

DigitalClock* digitalClock = new DigitalClock(timer) ;

При каждом срабатывании таймера timer оба экземпляра часов обновляют­ся и перерисовывают себя.

^ Известные применения

Первый и, возможно, самый известный пример паттерна наблюдатель по­явился в схеме модель/вид/контроллер (МУС) языка Smalltalk, которая пред­ставляет собой каркас для построения пользовательских интерфейсов в среде


Паттерн Observer

Smalltalk [KP88]. Класс Model в MVC - это субъект, a View - базовый-класс для наблюдателей. В языках Smalltalk, ET++ [ WGM88] и библиотеке классов THINK [Sym93b] предлагается общий механизм зависимостей, в котором интерфейсы субъекта и наблюдателя помещены в класс, являющийся общим родителем всех остальных системных классов.

Среди других библиотек для построения интерфейсов пользователя, в кото­рых используется паттерн наблюдатель, стоит упомянуть Interviews [LVC89], Andrew Toolkit [P+88] и Unidraw [VL90]. В Interviews явно определены классы Observer и Observable (для субъектов). В библиотеке Andrew они называют­ся видом (view) и объектом данных (data object) соответственно. Unidraw делит объекты графического редактора на части View (для наблюдателей) и Subject.

^ Родственные паттерны

Посредник: класс ChangeManager действует как посредник между субъек­тами и наблюдателями, инкапсулируя сложную семантику обновления.

Одиночка: класс ChangeManager может воспользоваться паттерном одиноч­ка, чтобы гарантировать уникальность и глобальную доступность менеджера из­менений.

^ Паттерн State

Название и классификация паттерна

Состояние - паттерн поведения объектов.

Назначение

Позволяет объекту варьировать свое поведение в зависимости от внутреннего состояния. Извне создается впечатление, что изменился класс объекта.

Мотивация

Рассмотрим класс TCPConnection, с помощью которого представлено сете­вое соединение. Объект этого класса может находиться в одном из нескольких со­стояний: Established (установлено), Listening (прослушивание), Closed (закрыто). Когда объект TCPConnection получает запросы от других объектов, то в зависимости от текущего состояния он отвечает по-разному. Например, ответ на запрос Open (открыть) зависит от того, находится ли соединение в состоянии Closed или Established. Паттерн состояние описывает, каким образом объект TCPConnect ion может вести себя по-разному, находясь в различных состояниях.

Основная идея этого паттерна заключается в том, чтобы ввести абстрактный класс TCPState для представления различных состояний соединения. Этот класс объявляет интерфейс, общий для всех классов, описывающих различные рабочие состояния. В подклассах TCPState реализовано поведение, специфичное для кон­кретного состояния. Например, в классах TCPEstabli shed и TCPClosed реали­зовано поведение, характерное для состояний Established и Closed соответ­ственно.

Паттерны поведения




Класс TCPConnect ion хранит у себя объект состояния (экземпляр некоторого подкласса TCPState), представляющий текущее состояние соединения, и деле­гирует все зависящие от состояния запросы этому объекту. TCPConnection ис­пользует свой экземпляр подкласса TCPState для выполнения операций, свойствен­ных только данному состоянию соединения.

При каждом изменении состояния соединения TCPConnection изменяет свой объект-состояние. Например, когда установленное соединение закрывается, TCPConnection заменяет экземпляр класса TCPEstablished экземпляром TCPCIosed.

Применимость

Используйте паттерн состояние в следующих случаях:

Q когда поведение объекта зависит от его состояния и должно изменяться во время выполнения;

О когда в коде операций встречаются состоящие из многих ветвей условные операторы, в которых выбор ветви зависит от состояния. Обычно в таком случае состояние представлено перечисляемыми константами. Часто одна и та же структура условного оператора повторяется в нескольких операци­ях. Паттерн состояние предлагает поместить каждую ветвь в отдельный класс. Это позволяет трактовать состояние объекта как самостоятельный объект, который может изменяться независимо от других.

Структура




Паттерн State

Участники

О Context (TCPConnection) - контекст:

- определяет интерфейс, представляющий интерес для клиентов;

- хранит экземпляр подкласса ConcreteState, которым определяется те­
кущее состояние;

Q State (TCPState) - состояние:

- определяет интерфейс для инкапсуляции поведения, ассоциированного
с конкретным состоянием контекста Context;

^ Q Подклассы ConcreteState (TCPEstablished, TCPListen, TCPClosed) -конкретное состояние:

- каждый подкласс реализует поведение, ассоциированное с некоторым со­
стоянием контекста Context.

Отношения

Q класс Context делегирует зависящие от состояния запросы текущему объ­екту ConcreteState;

Q контекст может передать себя в качестве аргумента объекту State, кото­рый будет обрабатывать запрос. Это дает возможность объекту-состоянию при необходимости получить доступ к контексту;

Q Context - это основной интерфейс для клиентов. Клиенты могут конфигу­рировать контекст объектами состояния State. Один раз сконфигуриро­вав контекст, Клиенты уже не должны напрямую связываться с объектами состояния;

О либо Context, либо подклассы ConcreteState могут решить, при каких условиях и в каком порядке происходит смена состояний.

Результаты

Результаты использования паттерна состояние:

Q локализует зависящее от состояния поведение и делит его на части, соот­ветствующие состояниям. Паттерн состояние помещает все поведение, ассо­циированное с конкретным состоянием, в отдельный объект. Поскольку зави­сящий от состояния код целиком находится в одном из подклассов класса State, то добавлять новые состояния и переходы можно просто путем порож­дения новых подклассов.

Вместо этого можно было бы использовать данные-члены для определения внутренних состояний, тогда операции объекта Context проверяли бы эти данные. Но в таком случае похожие условные операторы или операторы ветв­ления были бы разбросаны по всему коду класса Context. При этом добав­ление нового состояния потребовало бы изменения нескольких операций, что затруднило бы сопровождение.

Паттерн состояние позволяет решить эту проблему, но одновременно по­рождает другую, поскольку поведение для различных состояний оказыва­ется распределенным между несколькими подклассами State. Это увели­чивает число классов. Конечно, один класс компактнее, но если состояний