ПАКПС 5

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

УНИВЕРСИТЕТ ДУБНА
П.СЫЧЕВ
ЛЕКЦИЯ 5

2. Decorator

Тип: структурный.
Синоним: Wrapper.
Назначение: динамически добавляет объекту новые обязанности. Является гибкой
альтернативой порождению подклассов с целью расширения обязанностей.
Мотивация:
Иногда нужно добавить новые дополнительные обязанности конкретному объекту, а не
классу в целом. Конечно, есть стандартный способ – создать подкласс, добавив в него
дополнительную функциональность.

3. Decorator

Стандартный пример – текстовый компонент в графическом редакторе. Стандартный
компонент позволяет поместить текст внутри компонента. Сам компонент может
перемещаться внутри картинки, можно менять шрифт, его цвет и т.п.
Дополнительная функциональность:
- хочется иметь возможность включить рамку вокруг текста, с возможностью менять ее
толщину, цвет, стиль и т.п.
- хочется иметь прокрутку (Scroll), что позволяет поместить большой текст внутри
небольшого компонента и прокручивать его содержимое.
В стандартном подходе понадобятся три наследника класса TextView: BorderTextVew,
ScrollTextView, BorderScrollTextView для текста с рамкой, с прокруткой и с рамкой вместе с
прокруткой. А если надо добавить еще одно украшение?

4. Decorator

Идея декоратора проста – мы просто
создаем класс, наследник базового с
требуемой дополнительной
функциональностью. Но основную
функциональность перекладываем на
экземпляр класса, интегрированный в
объект. Например для рамки заведем
класс BorderDecoratorTextView.
class BorderDecoratorTextView : TextView
{
TextView view;
public override void Draw()
{
// draw Border
view.Draw();
}
}

5. Decorator

Структура
Client
Component
+Operation1()
+Operation2()
Component – базовый класс для семейства
компонентов;
1
+component
ConcreteComponent – конкретный класс
компонента;
ConcreteComponent
Decorator
+Operation1()
+Operation2()
+Operation1()
+Operation2()
1
component.Operation1();
Decorator – базовый класс для декораторов
ConcDecorator1 – декоратор с добавленной
функциональностью (методом);
ConcDecorator2 – декоратор с добавленным
состоянием.
ConcDecoratorA
+Operation1()
+Operation2()
+AddedMethod()
ConcDecoratorB
-AddedState
+Operation1()
+Operation2()

6. Decorator

Реализация
Класс Decorator использует отношение композиции. Указатель на декорируемый объект
инициализируется в конструкторе.
Класс Decorator делегирует выполнение операции декорируемому объекту.
Для реализации каждой дополнительной функциональности создайте класс, производный
от Decorator.
Подкласс Decorator реализует дополнительную функциональность и делегирует
выполнение операции базовому классу Decorator.
Клиент несет ответственность за конфигурирование системы: устанавливает типы и
последовательность использования основного объекта и декораторов.

7. Decorator

Результаты
(+) Большая гибкость, чем у статического наследования.
(+) Позволяет избежать перегруженных методами классов на верхних уровнях иерархии.
(-) Декоратор и его компонент, вообще говоря, не идентичны.
(-) Порождает большое число мелких объектов

8. Proxy

Тип: структурный.
Синоним: Surrogate.
Назначение: является суррогатом другого объекта и контролирует доступ к нему.

9. Proxy

Существует четыре ситуации, когда можно использовать паттерн Proxy:
1. Виртуальный proxy является заместителем объектов, создание которых
обходится дорого. Реальный объект создается только при первом
запросе/доступе клиента к объекту.
2. Удаленный proxy предоставляет локального представителя для объекта,
который находится в другом адресном пространстве ("заглушки" в RPC и
CORBA).
3. Защитный proxy контролирует доступ к основному объекту. "Суррогатный"
объект предоставляет доступ к реальному объекту, только если вызывающий
объект имеет соответствующие права.
4. Интеллектуальный proxy выполняет дополнительные действия при доступе к
объекту.

10. Proxy

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

11. Proxy

Структура
Subject – базовый класс
RealSubject – реальный класс субъекта
Proxy – заместитель, хранит ссылку на
реальный субъект. Реальные
обязанности зависят от назначения
заместителя.

12. Proxy

Реализация
Определяется назначением заместителя.
Для отложенной инициализации (виртуальный заместитель) – откладывает создание
субъекта до прямого обращения к нему.
Защищающий заместитель (Secure Stub) проверяет, имеет ли вызывающий необходимые
для запроса права.
Удаленный заместитель (Stub) отвечает за упаковку и передачу запроса реальному
субъекту в другом адресном пространстве, а также за получение, распаковку и возращение
результата.

13. Proxy

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

14. Facade

Тип: структурный.
Синоним: нет.
Назначение: предоставляет унифицированный интерфейс некоторой подсистемы.
Мотивация:
При разбиении сложной системы на подсистемы возникает задача – свести к минимуму
зависимость одной подсистемы от другой. Фасад – один из способов решения этой задачи,
предоставляет единый интерфейс для доступа к функциям подсистемы.
Например API Unix – является фасадом операционной системы для программиста.
Набор функций OpenGL – фасад большой библиотеки трехмерной графики.

15. Facade

Структура
Facade
Facade – фасад подсистемы
Elem1, Elem2, … - элементы
подсистемы
Elem1
Elem1
Elem1
…
Elem1

16. Facade

Реализация
Ключевой вопрос реализации – определение интерфейса фасада. Это определяет удобство
и гибкость работы с подсистемой. Сравните для примера API Unix и Windows.
Результаты
(+) изолирует клиента от деталей реализации подсистемы, что ослабляет связность.
(+) фасад не препятствует получение клиентом прямой ссылки на внутренний объект
подсистемы (через метод фасада) для увеличения эффективности взаимодействия.

17. Bridge

Тип: структурный.
Синоним: Handle/Body.
Назначение: отделяет абстракцию от реализации, так чтобы и то и другое можно было
изменять независимо.
Мотивация:
Рассмотрим иерархию графических примитивов, которые надо реализовать на различных
графических средах (GDI, .Net, DirectX). Идея состоит в том, что примитивы содержат
геометрические свойства, а для рисования используют специальный класс – рисовальщик.
Например, для иерархии графических примитивов реализацией может обеспечивать
вывод точки на дисплей. Абстракцией – класс точки, а её уточнениями – классы линии,
прямоугольника, круга и т.д. Все они используют исходную реализацию для рисования и
для того, чтобы перенести их на новую платформу достаточно заменить реализацию.

18. Bridge

Данный шаблон используется если необходимо:
a)
независимо изменять интерфейс работы с клиентом и реализацию;
b) (или) выбирать реализацию в процессе работы программы;
c)
(или) использовать одну реализацию в нескольких абстракциях;
d) (или) уменьшить число классов, получающихся при использовании наследования.

19. Bridge

Структура
Абстракция (Abstraction) – определяет
базовый интерфейс для работы с
клиентом.
Уточненная абстракция (Refined
abstraction) – наследует абстракцию и
вносит дополнительные свойства и
методы.
Реализация (Implementor) – определяет
интерфейс реализаций.
Конкретная реализация (Concrete
implementor) – обеспечивает
определенную функциональность.

20. Bridge

Реализация
Очень важным моментом в проектировании Моста является разработка двух интерфейсов:
абстракции и её взаимодействия с реализацией. Чем меньше будет в них привязка к
конкретной реализации, тем проще будет заменить её в дальнейшем. Например,
использование для задания координаты класса Point из .NET усложнит последующий
перенос на WinAPI.
При порождении экземпляра объекта, выбор конкретной реализации можно переложить
на порождающие шаблоны Фабричный метод или Абстрактная фабрика. Кроме того, они
же могут применяться для определения нужной клиенту уточненной абстракции.

21. Bridge

Результаты
(+) Проще расширять систему новыми типами за счет сокращения общего числа
родственных подклассов.
(+) Возможность динамического изменения реализации в процессе выполнения
программы.
(+) Паттерн Bridge полностью скрывает реализацию от клиента. В случае модификации
реализации пользовательский код не требует изменений.
(+) Обе стороны – и абстракция и реализация – могут изменяться независимо

22. Flyweight

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

23. Flyweight

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

24. Flyweight

Классы, описывающие различных
насекомых Ant (муравей), Locust (саранча)
и Cockroach (таракан) могут быть
"легковесными", потому что специфичная
для экземпляров информация может быть
вынесена наружу и затем, передаваться
клиентом в запросе.
Класс Factory необходим для создания
новых экземпляров или получения ссылки
на уже существующий экземпляр.

25. Flyweight

Структура

26. Flyweight

Реализация
Разделите состояние целевого класса на разделяемое (внутреннее) и неразделяемое
(внешнее).
Удалите из атрибутов (членов данных) класса неразделяемое состояние и добавьте его в
список аргументов, передаваемых методам.
Создайте фабрику, которая может кэшировать и повторно использовать существующие
экземпляры класса.
Для создания новых объектов клиент использует эту фабрику вместо оператора new.
Клиент (или третья сторона) должен находить или вычислять неразделяемое состояние и
передавать его методам класса.
Основная проблема – разделение класса.

27. Flyweight

Результаты
(+) эффективная работа с большим числом мелких объектов
(-+) необходимость ведения базы данных Flyweight в FlyweightFactory, т.е. отслеживание
уже не используемых Flyweight.