ПАКПС 8

1. Проектирование, Архитектура и Конструирование Программных систем

Лекция 8
Сычев П.

2. Mediator

• Тип: поведенческий;
• Синоним: нет;
• Назначение:
Определяет объект, инкапсулирующий способ взаимодействия
множества объектов. Посредник обеспечивает слабую
связанность системы, избавляя объекты от необходимости явно
ссылаться друг на друга и позволяя тем самым независимо
изменять взаимодействия между ними.

3. Mediator

• Мотивация:
• Для примера рассмотрим
сложное диалоговое окно.
Манипуляции с элементами
этого диалога влияют на
другие элементы этого
диалога. Т.е. все элементы
должны знать друг о друге.

4. Mediator

• Как можно решить эту проблему. Завести посредника…

5. Mediator

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

6. Mediator

• Пример диаграммы последовательностей

7. Mediator

• Структура:

8. Mediator

• Реализация:
1) избавление от абстрактного класса Mediator. Если коллеги
работают только с одним посредником, то нет необходимости
определять абстрактный класс Mediator. Обеспечиваемая классом
Mediator абстракция позволяет коллегам работать с разными
подклассами класса Mediator и наоборот;
2) обмен информацией между коллегами и посредником.
Коллеги должны обмениваться информацией со своим
посредником только тогда, когда возникает представляющее
интерес событие. Одним из подходов к реализации посредника
является применение паттерна наблюдатель.

9. Mediator

• Результаты:
(+) снижает число порождаемых подклассов. Посредник
локализует поведение, которое в противном случае пришлось бы
распределять между несколькими объектами. Для изменения
поведения нужно породить подклассы только от класса
посредника Mediator, классы коллег Colleague можно
использовать повторно без каких бы то ни было изменений;
(+) устраняет связанность между коллегами. Посредник
обеспечивает слабую связанность коллег. Изменять классы
Colleague и Mediator можно независимо друг от друга;

10. Mediator

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

11. Mediator

• (+-) централизует управление. Паттерн посредник переносит
сложность взаимодействия в класс посредник. Поскольку
посредник инкапсулирует протоколы, то он может быть сложнее
отдельных коллег. В результате сам посредник становится
монолитом, который трудно сопровождать.

12. Memento

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

13. Memento

• Мотивация:
Иногда необходимо тем или иным способом зафиксировать
внутреннее состояние объекта. Такая потребность возникает,
например, при реализации контрольных точек и механизмов отката,
позволяющих пользователю отменить пробную операцию или
восстановить состояние после ошибки. Его необходимо где то
сохранить, чтобы позднее восстановить в нем объект.
• Паттерн хранитель поможет решить данную проблему. Хранитель – это
объект, в котором сохраняется внутреннее состояния другого объекта
– хозяина хранителя. Для работы механизма отката нужно, чтобы
хозяин предоставил хранитель, когда возникнет необходимость
записать контрольную точку состояния хозяина. Только хозяину
разрешено помещать в хранитель информацию и извлекать ее оттуда,
для других объектов хранитель непрозрачен.

14. Memento

• Структура:

15. Memento

• Отношения:

16. Memento

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

17. Memento

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

18. Memento

• Результаты:
(+) сохранение границ инкапсуляции. Хранитель позволяет
избежать раскрытия информации, которой должен
распоряжаться только хозяин, но которую тем не менее
необходимо хранить вне последнего. Этот паттерн экранирует
объекты от потенциально сложного внутреннего устройства
хозяина, не из меняя границы инкапсуляции;
(+) упрощение структуры хозяина. При других вариантах
дизайна, направленного на сохранение границ инкапсуляции,
хозяин хранит внутри себя версии внутреннего состояния,
которое запрашивали клиенты. Таким образом, вся
ответственность за управление памятью лежит на хозяине.

19. Memento

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

20. Memento

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

21. Template Method

• Тип: поведенческий
• Синоним: NVM – Not Virtual Method
• Назначение: определяет основу алгоритма и позволяет
подклассам переопределить некоторые шаги алгоритма, не
изменяя его структуру в целом.

22. Template Method

• Рассмотрим процесс
рисования абстрактного
визуального
компонента, который
должен быть основой
для конкретных
компонентов. Он может
быть примерно таким:
public void Display()
{
DoBeforePaint();
Paint();
DoAfterPaint();
}
protected virtual void DoBeforePaint()
{ }
protected virtual void Paint()
{
// default painting
}
protected virtual void DoAfterPaint()
{ }

23. Template Method

• Структура

24. Template Method

• Метод Display – изменять не следует. Он обеспечивает
«шаблонное» поведение.
• Методы BeforePaint и AfterPaint объявлены пустыми и их следует
заменить в наследниках. Если объявить их абстрактными – они
должны быть определены в наследниках.
• Метод Paint имеет поведение по умолчанию, например
рисование всех собственных компонентов, но может быть
переопределен в наследнике.

25. Template Method

• Когда применять?
следует использовать:
❑ чтобы однократно использовать инвариантные части алгоритма,
оставляя реализацию изменяющегося поведения на усмотрение
подклассов;
❑ когда нужно вычленить и локализовать в одном классе поведение,
общее для всех подклассов, дабы избежать дублирования кода.
Сначала идентифицируются различия в существующем коде, а затем
они выносятся в отдельные операции. В конечном итоге
различающиеся фрагменты кода заменяются шаблонным методом, из
которого вызываются новые операции;
❑ для управления расширениями подклассов. Можно определить
шаблонный метод так, что он будет вызывать операции-зацепки
(hooks) –в определенных точках, разрешив тем самым расширение
только в этих точках.

26. Template Method

• Реализация:
1) использование контроля доступа. Методы – зацепки следует
делать защищенными, чтобы избежать их прямого вызова
клиентом;
2) сокращение числа примитивных операций. Важно при
проектировании шаблонных методов максимально возможно
сократить число примитивных операций, которые должны быть
замещены в подклассах.
3) соглашение об именах. Выделить операции, которые
необходимо заместить, можно путем добавления к их именам
некоторого префикса.

27. Template Method

• Результаты:
• (+) Шаблонные методы – один из фундаментальных приемов
повторного использования кода. Они особенно важны в
библиотеках классов, поскольку предоставляют возможность
вынести общее поведение в библиотечные классы.
Шаблонные методы приводят к инвертированной структуре кода,
это реализация принципа инверсии зависимостей (Dependency
Inversion Principle). В данном случае это означает, что
родительский класс вызывает операции подкласса, а не наоборот

28. Template Method

• Важно, чтобы в шаблонном методе четко различались операциизацепки (которые можно замещать) и абстрактные операции
(которые нужно замещать). Чтобы повторно использовать
абстрактный класс с максимальной эффективностью, авторы
подклассов должны понимать, какие операции предназначены
для замещения.

29. Visitor

• Тип: поведенческий.
• Синоним: нет.
• Назначение:
Описывает операцию, выполняемую с каждым объектом из
некоторой структуры. Паттерн посетитель позволяет определить
новую операцию, не изменяя классы этих объектов.

30. Visitor

• Мотивация: предположим, мы делаем некоторое приложение
для автоматизации проектирования, например проектирование
печатных плат.
• Плата содержит различные компоненты – контактные площадки
различных форм и размеров, а также, дорожки, их соединяющие.
• Для проектируемой печатной платы определены некоторый
набор операций. Например – определить общую площадь
площадок и дорожек, что необходимо для операции серебрения
платы. Конечно, можно включить метод GetArea() в базовый
класс компонентов. Но это не гибко!
• Задача. Как сделать дизайн, расширяемый для числа операций?

31. Visitor

• Структура

32. Visitor

• Реализация:
1) Для обхода элементов коллекции целесообразно использовать
итератор;
2) Реализация метода VisitElem в Visitor может нарушать
инкапсуляцию, так как может требовать знание внутренней
структуры объекта Elem.
• Результаты:
(+) упрощает добавление новых операций. Достаточно добавить
новый Visitor;
(-) добавление новых классов элементов затруднено, так как
требует добавление нового метода во все, ранее созданные
визиторы;

33. Visitor

• (+) позволяет обходить элементы разных классов, не обязательно
имеющих общий базовый класс;
(+) позволяет накапливать какую-то общую информацию по всем
элементам коллекции, так как визитор – полноценный класс;
(-) возможны нарушения инкапсуляции. Класс Elem должен
предоставлять достаточно широкий интерфейс, чтобы посетитель
мог выполнить свою работу.