Лекция № 8 Типовые решения проектирования. Паттерны поведения

Лекция № 8
Типовые решения проектирования.
Паттерны поведения
Основная цель: распределение обязанностей
между объектами на уровне проектирования.
Особенности:
 Элементами являются классы, объекты,
способы взаимодействия.
 Обрабатывается (реализуется) сложный
поток управления.
 Основной упор на связи между объектами,
задействованными в потоке, а не на сам
поток.
Паттерны поведения уровня классов.
Распределение поведения реализуется за счет
наследования.

Шаблонный метод (Template Method) –
пошаговое абстрактное определение алгоритма в виде
последовательности шагов

Интерпретатор (Interpreter)
представляет грамматику языка в виде совокупности
классов и реализует интерпретатор, как
последовательность операций на экземплярами этих
классов
Шаблонный метод (Template Method)
Диаграмма классов
AbstractClass
TemplateMethod()
PrimitiveOperation1()
PrimitiveOperation2()
ConcreteClass
PrimitiveOperation1()
PrimitiveOperation2()
Шаблонный метод (Template Method)
Применимость:



Однократное использование инвариантных частей
алгоритма, для реализации изменяющегося
поведения вводятся подклассов;
Обобщение и локализация в рамках одного класса
общего поведения;
для управления расширениями подклассов. Можно
определить шаблонный метод так, что он будет
вызывать операции-зацепки (hooks) в определенных
точках, разрешив тем самым расширение только в
этих точках.
Шаблонный метод (Template Method)
Реализация:



использование контроля доступа. (Защищенность –
обеспечивает вызов только в рамках шаблонного
метода. Абстрактность – обеспечивает
обязательность замещения);
сокращение числа примитивных операций. (Чем
больше операций нужно замещать, тем сложнее
использовать);
соглашение об именах. Выделить операции, которые
необходимо заместить, можно путем добавления к их
именам некоторого префикса.
Паттерны поведения уровня объектов.
Распределение поведения реализуется за счет
композиции. Основные особенности:
1.
2.



Это яркий пример кооперации;
Способ передачи информации о существовании
друг друга. (Проблема увеличения степени
связанности):
Посредник (Mediator) обеспечивает косвенность
ссылок между объектами-коллегами;
Цепочка обязанностей (Chain Of Responsibility)
косвенная обработка запросов по цепочке
объектов-кандидатов;
Наблюдатель (Observer) – определяет и отвечает за
зависимости между объектами.
Паттерны поведения уровня объектов.
3.





Инкапсуляция поведения в рамках класса
(объекта) и способ делегирования ему запросов:
Стратегия (Strategy) инкапсулирует алгоритм на
уровне класса, упрощая его спецификацию и
замену;
Команда (Command) – инкапсулирует запрос в виде
класса (объекта), который можно передавать в
качестве параметра, хранить с списке истории и
т.д. и т.п.;
Состояние (State) – инкапсулирует состояние
объекта таким образом, чтобы при изменении
состояния объект мог менять поведение;
Посетитель (Visitor) инкапсулирует поведение,
которое в противном случае пришлось бы
распределять между классами;
Итератор (Iterator) абстрагирует способ доступа и
обхода объектов из некоторого агрегата.
Посредник (Mediator)
Мотивация
Городской центр
Постройки
Зернохранилище
Бараки
Здание суда
Ресурсы
- 2386
Описание
- 534
- 484
Текущее строительство
...
- 14131
Посредник (Mediator)
Мотивация. Структура
aActiveWindowInterface Element
aGamer
aTownCentreDirector
Посредник
Посредник
aWindowInterface Element1
aWindowInterface ElementN
Посредник
Посредник
Посредник (Mediator)
Мотивация. Диаграмма последовательностей
aGamer
aTownCentreDirector
aActiveWindowInterface
Element
ShowDialog
IwasChanged
SetStatus
ActiveChanges
aWindowInterface Element1
aWindowInterface ElementN
Посредник (Mediator)
Диаграмма классов
Mediator
ConcreteMediator
Colleague
ConcreteColleague1
ConcreteColleague2
Посредник (Mediator)
Применимость:



имеются объекты, со сложными, но четко
определенными связями;
очевидная возможность повторного использования
объекта в текущем дизайне не поддерживается из-за
текущих информационных связей объекта;
поведение обладает следующими свойствами: вопервых, оно распределено между несколькими
классами, во-вторых, это поведение достаточно
разнообразно (его МНОГО), наконец, его хочется
настраивать не порождая подклассы.
Посредник (Mediator)
Результаты:





снижает число порождаемых подклассов. Посредник локализует
поведение, которое в противном случае пришлось бы распределять
между несколькими объектами;
устраняет связанность между коллегами. Посредник обеспечивает
слабую связанность коллег;
упрощает протоколы взаимодействия объектов. Посредник
заменяет дисциплину взаимодействия «все со всеми» дисциплиной
«один со всеми», то есть один посредник взаимодействует со всеми
коллегами. Отношения вида «один ко многим» проще для понимания,
сопровождения и расширения;
абстрагирует способ кооперирования объектов. Выделение
механизма посредничества в отдельную концепцию и инкапсуляция ее
в одном объекте позволяет сосредоточиться именно на
взаимодействии объектов, а не на их индивидуальном поведении. Это
дает возможность прояснить имеющиеся в системе взаимодействия;
централизует управление. Паттерн посредник переносит сложность
взаимодействия в класс-посредник. Поскольку посредник
инкапсулирует протоколы, то он может быть сложнее отдельных коллег.
В результате сам посредник становится монолитом, который трудно
сопровождать.
Посредник (Mediator)
Реализация:



избавление от абстрактного класса Mediator;
обмен информацией между коллегами и посредником.
Коллеги должны обмениваться информацией со своим
посредником только тогда, когда возникает
представляющее интерес событие. Одним из подходов
к реализации посредника является применение
паттерна наблюдатель. Тогда классы коллег действуют
как субъекты, посылающие извещения посреднику о
любом изменении своего состояния. Посредник
реагирует на них, сообщая об этом другим коллегам.
Другой подход: в классе Mediator определяется
специализированный интерфейс уведомления,
который позволяет коллегам обмениваться
информацией более свободно.
Паттерны поведения уровня объектов.
3.





Инкапсуляция поведения в рамках класса
(объекта) и способ делегирования ему запросов:
Стратегия (Strategy) инкапсулирует алгоритм на
уровне класса, упрощая его спецификацию и
замену;
Команда (Command) – инкапсулирует запрос в виде
класса (объекта), который можно передавать в
качестве параметра, хранить с списке истории и
т.д. и т.п.;
Состояние (State) – инкапсулирует состояние
объекта таким образом, чтобы при изменении
состояния объект мог менять поведение;
Посетитель (Visitor) инкапсулирует поведение,
которое в противном случае пришлось бы
распределять между классами;
Итератор (Iterator) абстрагирует способ доступа и
обхода объектов из некоторого агрегата.
Стратегия (Strategy)
Мотивация
Необходимо реализовать компьютерных противников и
определить алгоритм их поведения:
 Если включить алгоритм поведения в класс-клиент
(Противник) этот класс усложнится;
 В зависимости от внешних факторов хочется
применять тот или иной алгоритм поведения, при
этом не хочется инициализировать лишние, если они
сейчас не нужны;
 Если поведение неотъемлемая часть классаклиента, то добавление нового поведения
усложняется.
Стратегия (Strategy)
Мотивация. Структура
AIPlayer
Developer
TownDeveloper
TownBuild()
NextBuilding()
WarDeveloper
CompleteDeveloper
CultureDeveloper
NextBuilding()
NextBuilding()
NextBuilding()
Стратегия (Strategy)
Диаграмма классов
Context
Strategy
ContextInterface()
Context – контекст
• конфигурируется
объектом потомком
Strategy;
• хранит ссылку на
экземпляр объекта
класса Strategy;
• может определить
интерфейс, который
позволяет объекту
Strategy получить
доступ к данным
контекста.
Strategy – стратегия
• объявляет общий для все
алгоритмов интерфейс.
Класс Context использует
этот интерфейс для вызова
конкретного алгоритма,
Strategy
который реализуется в
рамках операции класса
AlgorithmInterface()ConcreteStrategy
ConcreteStrategyA
ConcreteStrategyB
ConcreteStrategyC
AlgorithmInterface()
AlgorithmInterface()
AlgorithmInterface()
ConcreteStrategy – конкретная стратегия
• реализует конкретный алгоритм,
удовлетворяющий объявленному в классе
Strategy интерфейсу.
Стратегия (Strategy)
Отношения


классы Strategy и Context взаимодействуют для
реализации выбранного алгоритма. Контекст может
передать стратегии все необходимые алгоритму
данные в момент его вызова. Вместо этого контекст
может позволить обращаться к своим операциям в
нужные моменты, передав ссылку на самого себя
операциям класса Strategy;
контекст переадресует запросы своих клиентов
объекту-стратегии. Обычно клиент создает объект
ConcreteStrategy и передает его контексту, после чего
клиент «общается» исключительно с контекстом.
Часто в распоряжении клиента находится несколько
классов ConcreteStrategy, которые он может
выбирать.
Стратегия (Strategy)
Применимость:




имеется много родственных классов, отличающихся только
поведением. Стратегия позволяет сконфигурировать класс,
задав одно из возможных поведений;
нужно иметь несколько разных вариантов алгоритма. Например,
можно определить два варианта алгоритма, один из которых
требует больше времени, а другой - больше памяти. Стратегии
разрешается применять, когда варианты алгоритмов
реализованы в виде иерархии классов;
в алгоритме содержатся данные, о которых клиент не должен
знать. Используйте паттерн стратегия, чтобы не раскрывать
сложные, специфичные для алгоритма структуры данных;
в классе определено много поведений, что представлено
разветвленными условными операторами. В этом случае проще
перенести код из ветвей в отдельные классы стратегий.
Стратегия (Strategy)
Результаты – «бочка мёда» :


Организация семейств родственных алгоритмов. Иерархия классов Strategy
определяет семейство алгоритмов или поведений, которые можно повторно
использовать в разных контекстах. Наследование позволяет вычленить общую
для всех алгоритмов функциональность;
Альтернатива порождению подклассов. Наследование поддерживает
многообразие алгоритмов или поведений. Можно напрямую породить от Context
подклассы с различными поведениями. Но ..
•
•
•
•


при этом поведение жестко «зашивается» в класс Context.
реализации алгоритма и контекста смешиваются, что затрудняет понимание,
сопровождение и расширение контекста.
заменить алгоритм динамически уже не удастся.
получаем множество родственных классов, отличающихся только алгоритмом (и) или
поведением.
Инкапсуляции алгоритма в отдельный класс Strategy позволяют изменять его
независимо от контекста;
С помощью стратегий можно избавиться от условных операторов.
Благодаря паттерну стратегия удается отказаться от условных операторов при
выборе нужного поведения. Когда различные поведения помещаются в один
класс, трудно выбрать нужное без применения условных операторов.
Инкапсуляция же каждого поведения в отдельный класс Strategy решает эту
проблему.
выбор реализации. Стратегии могут предлагать различные реализации одного и
того ж- поведения. Клиент вправе выбирать подходящую стратегию в
зависимости от своих требований к быстродействию и памяти;
Стратегия (Strategy)
Результаты – «ложка дегтя» :



клиенты должны «знать» о различных стратегиях. Потенциальный
недостаток этого паттерна в том, что для выбора подходящей стратегии клиент
должен понимать, чем отличаются разные стратегии. Поэтому наверняка
придется раскрыть клиенту некоторые особенности её реализации. Отсюда
следует, что паттерн стратегия стоит применять лишь тогда, когда различия в
поведении имеют значение для клиента;
обмен информацией между стратегией и контекстом. Интерфейс класса
Strategy разделяется всеми подклассами ConcreteStrategy - неважно, сложна
или тривиальна их реализация. Поэтому вполне вероятно, что некоторые
стратегии не будут пользоваться всей передаваемой им информацией,
особенно простые. Это означает, что в отдельных случаях контекст создаст и
проинициализирует параметры, которые никому не нужны. Если возникнет
проблема, то между классами Strategy и Context придется установить более
тесную связь;
увеличение числа классов/объектов. Применение стратегий увеличивает число
объектов в приложении. Иногда эти издержки можно сократить, если
реализовать стратегии в виде объектов без состояния, которые могут
разделяться несколькими контекстами. Остаточное состояние хранится в самом
контексте и передается при каждом обращении к объекту-стратегии.
Разделяемые стратегии не должны сохранять состояние между вызовами.
Стратегия (Strategy)
Реализация:

определение интерфейсов классов Strategy и Context. Интерфейсы классов Strategy и
Context могут обеспечить объекту класса ConcreteStrategy эффективный доступ к
любым данным контекста, и наоборот.
•
•


Context передает данные в виде параметров операциям класса Strategy. Это разрывает тесную
связь между контекстом и стратегией. При этом не исключено, что контекст будет передавать
данные, которые стратегии не нужны.
Передать контекст в качестве аргумента, в таком случае стратегия будет запрашивать у него
данные, причем только необходимые данные, или, например, сохранить ссылку на свой
контекст, так что передавать вообще ничего не придется. Но тогда в контексте должен быть
определен более развитый интерфейс к своим данным, что несколько усиливает связанность
классов Strategy и Context.
Какой подход лучше, зависит от конкретного алгоритма и требований, которые он
предъявляет к данным;
стратегии как параметры шаблона. В C++ для конфигурирования класса стратегией
можно использовать шаблоны. Этот способ хорош, только если стратегия определяется
на этапе компиляции и ее не нужно менять во время выполнения. Тогда
конфигурируемый класс (например, Context) определяется в виде шаблона, для
которого класс Strategy является параметром. При использовании шаблонов отпадает
необходимость в абстрактном классе для определения интерфейса Strategy. Кроме
того, передача стратегии в виде параметра шаблона позволяет статически связать
стратегию с контекстом, вследствие чего повышается эффективность программы;
объекты-стратегии можно не задавать. Класс Context разрешается упростить, если для
него отсутствие какой бы то ни было стратегии является нормой. Прежде чем
обращаться к объекту Strategy, объект Context проверяет наличие стратегии. Если да,
то работа продолжается как обычно, в противном случае контекст реализует некое
поведение по умолчанию. Достоинство такого подхода в том, что клиентам вообще не
нужно иметь дело со стратегиями, если их устраивает поведение по умолчанию.
Состояние (State)
Мотивация:
status-->StartProduction()
TownBuilding
State
Status
StartProduction()
StartProduction()
NotPresentStatus
StartProduction()
NotUsedStatus
StartProduction()
ProductionStatus
StartProduction()
Состояние (State)
Диаграмма классов
Context
State
RequestA()
RequestB()
Context – контекст
• определяет
интерфейс,
представляющий
интерес для клиентов;
- хранит экземпляр
подкласса
ConcreteState, которым
определяется текущее
ConcreteStateA
состояние;
State – состояние:
- определяет интерфейс для
инкапсуляции поведения,
Stateассоциированного с
конкретным состоянием
контекста Context;
HandleA()
HandleB()
ConcreteStateB
...
HandleA()
HandleB()
HandleA() – каждый подкласс реализует
ConcreteState
HandleB()ассоциированное с некоторым
поведение,
состоянием контекста Context.
Состояние (State)
Отношения




класс Context делегирует зависящие от состояния
запросы текущему объекту ConcreteState;
контекст может передать себя в качестве аргумента
объекту State, который будет обрабатывать запрос.
Это дает возможность объекту-состоянию при
необходимости получить доступ к контексту;
Context - это основной интерфейс для клиентов.
Клиенты могут конфигурировать контекст объектами
состояния State. Один раз сконфигурировав контекст,
клиенты уже не должны напрямую связываться с
объектами состояния;
либо Context, либо подклассы ConcreteState могут
решить, при каких условиях и в каком порядке
происходит смена состояний.
Состояние (State)
Применимость:


когда поведение объекта зависит от его состояния и
должно изменяться по время выполнения;
когда в коде операций встречаются состоящие из
многих ветвей условные операторы, в которых выбор
ветви зависит от состояния. Обычно в таком случае
состояние представлено перечисляемыми
константами. Часто одна и та же структура условного
оператора повторяется в нескольких операциях.
Паттерн состояние предлагает поместить каждую
ветвь в отдельный класс. Это позволяет трактовать
состояние объекта как самостоятельный объект,
который может изменяться независимо от других.
Состояние (State) . Результаты:




локализует зависящее от состояния поведение и делит его на части,
соответствующие состояниям. Паттерн состояние помещает все поведение,
ассоциированное с конкретным состоянием, в отдельный объект. Поскольку зависящий
от состояния код целиком находится в одном из подклассов класса State, то добавлять
новые состояния и переходы можно просто путем порождения новых подклассов.
поведение для различных состояний оказывается распределенным между
несколькими подклассами State. Это увеличивает число классов. Конечно, один класс
компактнее, но если состояний много, то такое распределение эффективнее, так как в
противном случае пришлось бы иметь дело с громоздкими условными операторами.
Паттерн состояние предлагает более удачный способ структурирования зависящего от
состояния кода. Логика, описывающая переходы между состояниями, больше не
заключена в монолитные операторы if или switch, а распределена между подклассами
State. При инкапсуляции каждого перехода и действия в класс состояние становится
полноценным объектом. Это улучшает структуру кода и проясняет его назначение;
делает явными переходы между состояниями. Если объект определяет свое текущее
состояние исключительно в терминах внутренних данных, то переходы между
состояниями не имеют явного представления; они проявляются лишь как присваивания
некоторым атрибутам. Ввод отдельных объектов для различных состояний делает
переходы более явными. Кроме того, объекты State могут защитить контекст Context от
рассогласования внутренних переменных, поскольку переходы с точки зрения контекста
- это атомарные действия. Для осуществления перехода надо изменить значение
только одной переменной (объектной переменной State в классе Context), а не
нескольких;
объекты состояния можно разделять. Если в объекте состояния State отсутствуют
переменные экземпляра, то есть представляемое им состояние кодируется
исключительно самим типом, то разные контексты могут разделять один и тот же
объект State. Когда состояния разделяются таким образом, они являются, по сути дела,
приспособленцами, у которых нет внутреннего состояния, а есть только поведение.
Состояние (State).Реализация:

что определяет переходы между состояниями. Паттерн состояние ничего не сообщает
о том, какой участник определяет критерий перехода между состояниями.
• Если критерии зафиксированы, то их можно реализовать непосредственно в классе
Context.
• Однако в общем случае более гибкий и правильный подход заключается в том, чтобы
позволить самим подклассам класса State определять следующее состояние и
момент перехода. Для этого в класс Context надо добавить интерфейс, позволяющий
объектам State установить состояние контекста.
Такую децентрализованную логику переходов проще модифицировать и расширять нужно лишь определить новые подклассы State. Недостаток децентрализации в том,
что каждый подкласс State должен «знать» еще хотя бы об одном подклассе, что
вносит реализационные зависимости между подклассами;
• табличная альтернатива. Используется таблица для отображения входных данных,
влияющих на переходы между состояниями, С ее помощью можно определить, н
какое состояние нужно перейти при поступлении некоторых входных данных. Тем
самым заменятся условный код (или виртуальные функции) поиском в таблице.
Основное преимущество таблиц - в их регулярности: для изменения критериев
перехода достаточно модифицировать только данные, а не код. Но есть и
недостатки:
- поиск в таблице часто менее эффективен, чем вызов функции (виртуальной);
- представление логики переходов в однородном табличном формате делает
критерии менее явными и, стало быть, более сложными для понимания;
- обычно трудно добавить, действия, которыми сопровождаются переходы между
состояниями. Табличный метод учитывает состояния и переходы между ними, но его
необходимо дополнить, чтобы при каждом изменении состоянии можно было
выполнять произвольные вычисления.
Главное различие между конечными автоматами на базе таблиц и паттерном
состояние можно сформулировать так: паттерн состояние моделирует
поведение, зависящее от состояния, а табличный метод акцентирует внимание
на определении переходов между состояниями;
Состояние (State)
Реализация:


создание и уничтожение объектов состояния. В процессе разработки обычно
приходится выбирать между:
- созданием объектов состояния, когда в них возникает необходимость, и
уничтожением сразу после использования;
- созданием их заранее и навсегда.
Первый вариант предпочтителен, когда заранее неизвестно, в какие состояния
будет попадать система, и контекст изменяет состояние сравнительно редко.
При этом мы не создаем объектов, которые никогда не будут использованы,
что существенно, если в объектах состояния хранится много информации.
Когда изменения состояния происходят часто, поэтому не хотелось бы
уничтожать представляющие их объекты (ибо они могут очень скоро
понадобиться вновь), следует воспользоваться вторым подходом. Время на
создание объектов затрачивается только один раз, в самом начале, а на
уничтожение - не затрачивается вовсе. Правда, этот подход может оказаться
неудобным, так как и контексте должны храниться ссылки на все состояния, в
которые система теоретически может попасть;
использование динамического наследования. Варьировать поведение по
запросу можно, меняя класс объекта во время выполнения, но в большинстве
объектно-ориентированных языков это не поддерживается.
Обсуждение паттернов поведения.
Инкапсуляция вариантов - элемент многих паттернов
поведения.
Ситуация: некоторый элемент системы подвержен периодическим
изменениям. Паттерны поведения позволяют определить пары
класс/объект для инкапсуляции этих изменений. Обычно такие
паттерны определяют абстрактный класс для описания
инкапсулируемых поведений, при этом имя паттерна, чаще всего,
совпадает с инкапсулируемым элементом системы.
 Стратегия – инкапсулирует алгоритм;
 Состояние – инкапсулирует поведение, зависящее от состояния;
 Посредник – инкапсулирует протокол общения между элементами;
 Итератор – инкапсулирует способ доступа и обхода сложного
(композитного) объекта.
Обсуждение паттернов поведения.
Инкапсуляция вариантов - элемент многих паттернов
поведения.
Перечисленные паттерны инкапсулируют элементы системы,
подверженные изменениям. В них фигурирует два вида классов:
новый класс, который инкапсулирует изменяющуюся часть, и
старый класс (или классы), который использует новый.
Причем, если бы не паттерн, то функциональность, которая теперь
лежит внутри новых классов, пришлось бы реализовывать в
рамках существующих (старых) классов.
Исключение цепочка обязанностей . Она иллюстрирует важный
элемент паттернов поведения – в отличие от других шаблонов
она показывает как организовать обмен информацией между
неизвестным заранее числом объектов, причем все они могут
уже существовать в системе.
Обсуждение паттернов поведения.
Объекты в качестве аргументов.
В нескольких паттернах поведения участвует объект, который
всегда используется только как аргумент.
 Посетитель – объект-посетитель является аргументом
полиморфной операции, которая принадлежит посещаемому
объекту. Посетитель некогда не является частью объектов,
которые он посещает.
 Команда и хранитель – определяют объект-параметр, который
передается в виде контейнера от одного владельца другому и
может быть задействован в будущем. В команде контейнер –
это запрос, а в хранителе – это внутреннее состояние.
Обсуждение паттернов поведения.
Варианты обмена информацией (инкапсуляция или
распределение).
Паттерны-антагонисты Посредник и Наблюдатель.
Принципиальная разница: наблюдатель распределяет обмен
информацией за счет объектов наблюдатель и субъект, а
посредник инкапсулирует взаимодействие между другими
объектами.
В наблюдателе наблюдатель и субъект должны кооперироваться,
чтобы поддерживать ограничение. А в посреднике вся
ответственность за поддержку ограничения лежит только на
посреднике.
Повторно использовать наблюдатели и субъекты проще, с другой
стороны посредник – проще в плане организации и понимания
потоков информации.
Обсуждение паттернов поведения.
Разделение получателей и отправителей
Когда объекты непосредственно ссылаются
друг на друга увеличивается степень
связанности. Паттерны команда,
наблюдатель, посредник и цепочка
обязанностей определяют разные способы
разделения получателей и отправителей
запросов. У каждого свои достоинства и
недостатки.
Обсуждение паттернов поведения.
Разделение получателей и отправителей.
Команда поддерживает разделение за счет объектакоманды, который и определяет привязку отправителя к
получателю.
Предоставляет простой интерфейс для выдачи запроса
(Execute);
:aInvoker (отправитель)
Так как связь между отправителем и получателем
инкапсулирована в отдельный объект (aCommand),
отправитель
может работать с разными
получателями;
:aReceiver
(Получатель)
:aCommand
Отделение отправителя от получателя облегчает
повторное использование. Кроме того повторно можно
использовать сам объект команду, для параметризации
Execute()
получателя различными отправителями
(Sender);
Action()
Формально требуется определить подкласс команду для
каждой связи отправитель-получатель.
Обсуждение паттернов поведения.
Разделение получателей и отправителей.
Наблюдатель отделяет отправителей (субъектов) от
получателей (наблюдателей) путем определения
интерфейса для извещения об изменениях.
:aSubject (отправитель)
:aObserver(Получатель)
По сравнению
Update()
:aObserver(Получатель)
:aObserver(Получатель)
с Командой
связь между Отправителем
и
Получателем слабее;
У одного отправителя может быть несколько получателей,
причем их число может меняться даже во время
выполнения;
Интерфейсы
в этом паттерне предназначены для передачи
Update()
информации об изменениях. А значит он употребим (лучше
подходит) когда между отправителями и получателями
есть зависимость
Update()по данным.
Обсуждение паттернов поведения.
Разделение получателей и отправителей.
Посредник поддерживает разделение, заставляя объекты
косвенно ссылаться друг на друга через объектпосредник.
:aColleague (отправитель/
получатель)
:aMediator
:aColleague (отправитель/
получатель)
:aColleague (отправитель/
получатель)
Объект-посредник централизует обмен информацией
между объектами-коллегами и распределяет его;
Интерфейс посредника фиксирован, за счет этого
посредник может реализовать собственную гибкую
систему диспетчеризации;
Можно кодировать запросы, упаковывать аргументы за
счет чего коллеги могут заращивать операции из заранее
неизвестного подмножества;
За счет централизации обмена информации уменьшается
число подклассов в системе;
Коллеги могут обещаться между собой только через
интерфейс посредника. Толстый посредник
Обсуждение паттернов поведения.
Разделение получателей и отправителей.
Цепочка обязанностей отделяет отправителя от
получателя за счет передачи запроса по цепочке
потенциальных получателей.
:aClient (Отправитель)
Гибкость повышается
за счет того, что цепочку
очень легко
:aHandler(получатель)
:aHandler(получатель)
:aHandler(получатель)
Handle()
расширять;
Хороший способ разделить отправителей и получателей,
если цепочка уже является частью системы и один объект
из группы может принять на себя обязанности
распорядителя
цепочки;
Handle()
Так как интерфейсы фиксированы может
потребоваться
Handle()
некоторая схема диспетчаторизации;
Обладает теми же недостатками, что и посредник, с точки
зрения безопасности типов.