Декоратор (шаблон проектирования): различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
[непроверенная версия][непроверенная версия]
Содержимое удалено Содержимое добавлено
агрегация не так хороша, как декоратор
ограничения аггрегации в COM
Строка 49: Строка 49:
Драйверы-фильтры в ядре [[Windows]] (архитектура [[Windows Driver Model|WDM (Windows Driver Model)]]) представляют собой декораторы. Несмотря на то, что WDM реализована на не-объектном языке [[Си (язык программирования)|Си]], в ней четко прослеживаются паттерны проектирования — декоратор, [[цепочка обязанностей]], и [[Команда (шаблон проектирования)|команда]] (объект [[IRP]]).
Драйверы-фильтры в ядре [[Windows]] (архитектура [[Windows Driver Model|WDM (Windows Driver Model)]]) представляют собой декораторы. Несмотря на то, что WDM реализована на не-объектном языке [[Си (язык программирования)|Си]], в ней четко прослеживаются паттерны проектирования — декоратор, [[цепочка обязанностей]], и [[Команда (шаблон проектирования)|команда]] (объект [[IRP]]).


Архитектура [[Component Object Model|COM (Component Object Model)]] не поддерживает наследование реализаций, вместо него предлагается использовать декораторы (в данной архитектуре это называется «агрегация», хотя функционально агрегация уже, чем декоратор). При этом архитектура решает (с помощью механизма pUnkOuter) проблему object identity, возникающую при использовании декораторов — identity агрегата есть identity его самого внешнего декоратора.
Архитектура [[Component Object Model|COM (Component Object Model)]] не поддерживает наследование реализаций, вместо него предлагается использовать декораторы (в данной архитектуре это называется «агрегация»). При этом архитектура решает (с помощью механизма pUnkOuter) проблему object identity, возникающую при использовании декораторов — identity агрегата есть identity его самого внешнего декоратора. Функционально агрегация уже, чем декоратор. Дело в том, что объект-компонент, на который накладывается аггрегация, изначально должен быть т. наз. аггрегируемым.


== Примеры ==
== Примеры ==

Версия от 18:00, 28 мая 2017

Декоратор
Decorator
Представление структуры шаблона Декоратор
Представление структуры шаблона Декоратор
Тип структурный
Назначение для динамического подключения к объекту дополнительных обязательств
Плюсы
  • нет необходимости создавать подклассы для расширения функциональности объекта;
  • возможность динамически подключать новую функциональность до или после основной функциональности объекта ConcreteComponent.
Родственные шаблоны Фасад, Адаптер
Описан в Design Patterns Да

Декоратор (англ. Decorator) — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту. Шаблон Декоратор предоставляет гибкую альтернативу практике создания подклассов с целью расширения функциональности.

Основные характеристики

Задача

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

Способ решения

Декоратор предусматривает расширение функциональности объекта без определения подклассов.

Участники

Класс ConcreteComponent — класс, в который с помощью шаблона Декоратор добавляется новая функциональность. В некоторых случаях базовая функциональность предоставляется классами, производными от класса ConcreteComponent. В подобных случаях класс ConcreteComponent является уже не конкретным, а абстрактным. Абстрактный класс Component определяет интерфейс для использования всех этих классов.

Следствия

  1. Добавляемая функциональность реализуется в небольших объектах. Преимущество состоит в возможности динамически добавлять эту функциональность до или после основной функциональности объекта ConcreteComponent.
  2. Позволяет избегать перегрузки функциональными классами на верхних уровнях иерархии
  3. Декоратор и его компоненты не являются идентичными

Реализация

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

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

Замечания и комментарии

  • Хотя объект-декоратор может добавлять свою функциональность до или после функциональности основного объекта, цепочка создаваемых объектов всегда должна заканчиваться объектом класса ConcreteComponent.
  • Базовые классы языка Java широко используют шаблон Декоратор для организации обработки операций ввода-вывода.
  • И декоратор, и адаптер являются обёртками вокруг объекта — хранят в себе ссылку на оборачиваемый объект и часто передают в него вызовы методов. Отличие декоратора от адаптера в том, что адаптер имеет внешний интерфейс, отличный от интерфейса оборачиваемого объекта, и используется именно для стыковки разных интерфейсов. Декоратор же имеет точно такой же интерфейс, и используется для добавления функциональности.
  • Для расширения функциональности класса возможно использовать как декораторы, так и стратегии. Декораторы оборачивают объект снаружи, стратегии же вставляются в него внутрь по неким интерфейсам.
    • Недостаток стратегии: класс должен быть спроектирован с возможностью вставления стратегий, декоратор же не требует такой поддержки.
    • Недостаток декоратора: он оборачивает ровно тот же интерфейс, что предназначен для внешнего мира, что вызывает смешение публичного интерфейса и интерфейса кастомизации, которое не всегда желательно.

Применение шаблона

Драйверы-фильтры в ядре Windows (архитектура WDM (Windows Driver Model)) представляют собой декораторы. Несмотря на то, что WDM реализована на не-объектном языке Си, в ней четко прослеживаются паттерны проектирования — декоратор, цепочка обязанностей, и команда (объект IRP).

Архитектура COM (Component Object Model) не поддерживает наследование реализаций, вместо него предлагается использовать декораторы (в данной архитектуре это называется «агрегация»). При этом архитектура решает (с помощью механизма pUnkOuter) проблему object identity, возникающую при использовании декораторов — identity агрегата есть identity его самого внешнего декоратора. Функционально агрегация уже, чем декоратор. Дело в том, что объект-компонент, на который накладывается аггрегация, изначально должен быть т. наз. аггрегируемым.

Примеры

Java

C#

C++

D

Python

PHP

PHP 5

CoffeeScript

JavaScript

VB.NET

Delphi

Языки Delphi и Free Pascal поддерживают class helpers, которые делают ненужным использование шаблона декоратор.

Литература

  • Алан Шаллоуей, Джеймс Р. Тротт. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию = Design Patterns Explained: A New Perspective on Object-Oriented Design. — М.: «Вильямс», 2002. — С. 288. — ISBN 0-201-71594-5.
  • Эрик Фримен, Элизабет Фримен. Паттерны проектирования = Head First Desing Patterns. — СПб.: Питер. — 656 с. — ISBN 978-5-459-00435-9.

Ссылки