Также известен как Обёртка, Decorator

Декоратор

Суть паттерна

Декоратор — это структурный паттерн проектирования, который позволяет динамически добавлять объектам новую функциональность, оборачивая их в полезные «обёртки».

Паттерн Декоратор

Проблема

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

Основой библиотеки является класс Notificator с методом send, который принимает на вход строку-сообщение и высылает её всем администраторам по электронной почте. Сторонняя программа должна создать и настроить этот объект, указав кому слать оповещения, а затем использовать его каждый раз, когда что-то случается.

Структура библиотеки до применения декоратора

Сторонние программы используют главный класс оповещений.

В какой-то момент стало понятно, что одних email оповещений пользователям мало. Некоторые из пользователей хотели бы получать извещения о критических проблемах через SMS. Другие пользователи хотят получать их в виде сообщений Facebook. Корпоративные пользователи хотят видеть сообщения в Slack.

Библиотека после добавления других способов оповещений

Каждый способ оповещения живёт в собственном подклассе.

Сначала вы добавили каждый из этих видов оповещений в программу, унаследовав их от базового класса Notificator. Теперь пользователь выбирал один из видов оповещений, который и использовался в дальнейшем.

Но затем кто-то резонно спросил, почему нельзя выбрать несколько видов оповещений сразу? Ведь если вдруг загорается ваш дом, вы бы хотели получить оповещения по всем каналам, верно?

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

Библиотека после комбинирования оповещений

Комбинаторный взрыв подклассов при совмещении способов оповещений.

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

Решение

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

  • Он статичен. Вы не можете изменить поведение существующего объекта. Для этого вам надо создать новый объект, выбрав другой подкласс.
  • Он не разрешает наследовать поведение нескольких классов одновременно. Из-за этого вам приходится создавать множество подклассов-комбинаций для получения совмещённого поведения.

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

Наследование против Композиции

Наследование против Композиции

Декоратор имеет альтернативное название — «обёртка». Оно удачнее описывает суть паттерна: вы помещаете целевой объект в другой объект-обёртку, который запускает базовое поведение объекта, а затем добавляет к результату что-то своё.

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

В нашем примере с оповещениями, мы оставим в базовом классе простую отправку по электронной почте, а расширенные способы отправки сделаем декораторами.

Схема решения декоратором

Расширенные способы оповещения становятся декораторами.

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

Программа может составлять сложные стеки декораторов

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

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

Таким же образом можно изменять не только способ доставки оповещений, но и форматирование сообщения, список адресатов, и так далее. К тому же, клиент может «дообернуть» объект любыми другими обёртками, когда ему захочется.

Аналогия из жизни

Одежда

Пример паттерна Декоратор

Одежду можно надевать слоями.

Любая одежда — это аналог декоратора. Применяя декоратор, вы не меняете первоначальный класс и не создаёте дочерних классов. Так и с одеждой — надевая свитер, вы не перестаёте быть собой, но получаете новое свойство — защиту от холода. Вы можете пойти дальше и надеть сверху ещё один декоратор, плащ, чтобы защититься и от дождя.

Структура

Структура классов паттерна Декоратор
  1. Компонент задаёт общий интерфейс обёрток и оборачиваемых объектов.

  2. Конкретный Компонент определяет класс оборачиваемых объектов. Он содержит какое-то базовое поведение, которое потом изменяют декораторы.

  3. Базовый Декоратор хранит ссылку на вложенный объект-компонент. Им может быть как конкретный компонент, так и один из конкретных декораторов. Базовый декоратор делегирует все свои операции вложенному объекту. Дополнительное поведение будет жить в конкретных декораторах.

  4. Конкретные Декораторы — это различные вариации декораторов, которые содержат добавочное поведение. Оно выполняется до или после вызова аналогичного поведения обёрнутого объекта.

Псевдокод

В этом примере Декоратор защищает финансовые данные дополнительными уровнями безопасности прозрачно для кода, который их использует.

Приложение оборачивает класс данных в шифрующую и сжимающую обёртку, которые при чтении выдают оригинальные данные, а при записи — сжатые и зашифрованные.

Структура классов примера паттерна Декоратор

Пример шифрования и компрессии данных с помощью обёрток.

Декораторы, как и сам класс данных, имеют общий интерфейс. Поэтому клиентскому коду без разницы с чем работать.

// Общий интерфейс компонентов.
interface DataSource is
    method writeData(data)
    method readData():data

// Один из конкретных компонент, реализует базовую функциональность.
class FileDataSource implements DataSource is
    constructor FileDataSource(filename) { ... }

    method writeData(data) is
        Write data to file.

    method readData():data is
        Read data from file.

// Родитель всех Декораторов содержит код обёртывания.
class DataSourceDecorator implements DataSource is
    protected field wrappee: DataSource

    constructor DataSourceDecorator(source: DataSource) is
        wrappee = source

    method writeData(data) is
        wrappee.writeData(data)

    method readData():data is
        return wrappee.readData()

// Конкретные декораторы добавляют что-то своё к базовому поведению
// обёрнутого компонента.
class EncyptionDecorator extends DataSourceDecorator is
    method writeData(data) is
        Encrypt passed data.
        Pass the compressed data to wrappee's writeData() method.

    method readData():data is
        Get the data from wrappee's readData() method.
        Decrypt and return that data.

// Декорировать можно не только базовые компоненты, но и уже обёрнутые объекты.
class CompressionDecorator extends DataSourceDecorator is
    method writeData(data) is
        Compress passed data
        Pass the compressed data to wrappee's writeData() method.

    method readData():data is
        Get the data from wrappee's readData() method.
        Uncompress and return that data.



// Вариант 1. Простой пример сборки и использования декораторов.
class Application is
    method dumbUsageExample() is
        source = new FileDataSource('somefile.dat')
        source.writeData(salaryRecords)
        // В файл были записаны чистые данные.

        source = new CompressionDecorator(source)
        source.writeData(salaryRecords)
        // В файл были записаны сжатые данные.

        source = new EncyptionDecorator(source)
        // source — это связка из трёх объектов:
        // Encyption > Compression > FileDataSource
        source.writeData(salaryRecords)
        // В файл были записаны сжатые и зашифрованные данные.



// Вариант 2. Клиентский код, использующий внешний источник данных. Класс
// SalaryManager ничего не знает о том как именно будут считаны и записаны
// данные. Он получает уже готовый источник данных.
class SalaryManager is
    field source: DataSource

    constructor SalaryManager(source: DataSource) { ... }

    method load() is
        return source.readData()

    method save() is
        source.writeData(salaryRecords)
    // ...Остальные полезные методы...


// Приложение может по-разному собирать декорируемые объекты, в зависимости от
// условий использования.
class ApplicationConfigurator is
    method configurationExample() is
        source = new FileDataSource("salary.dat")
        if (enabledEncryption)
            source = new EncyptionDecorator(source)
        if (enabledCompression)
            source = new CompressionDecorator(source)

        logger = new SalaryLogger(source)
        salary = logger.load()
    // ...

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

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

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

Когда нельзя расширить обязанности объекта с помощью наследования.

Во многих языках программирования есть ключевое слово final, которое может заблокировать наследование класса. Расширить такие классы можно только с помощью Декоратора.

Шаги реализации

  1. Убедитесь, что в вашей задаче есть один основной компонент и несколько опциональных дополнений или надстроек над ним.

  2. Создайте интерфейс компонента, который описывал бы все общие методы как для основного компонента, так и для его дополнений.

  3. Создайте класс конкретного компонента и поместите в него основную бизнес-логику.

  4. Создайте базовый класс декораторов. Он должен иметь поле для хранения ссылки на вложенный объект-компонент. Все методы базового декоратора должны делегировать действие вложенному объекту.

  5. И конкретный компонент, и базовый декоратор должны следовать одному и тому же интерфейсу компонента.

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

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

Преимущества и недостатки

  • Большая гибкость, чем у наследования.
  • Позволяет добавлять обязанности на лету.
  • Можно добавлять несколько новых обязанностей сразу.
  • Позволяет иметь несколько мелких объектов вместо одного объекта на все случаи жизни.
  • Трудно конфигурировать многократно обёрнутые объекты.
  • Обилие крошечных классов.

Отношения с другими паттернами

  • Адаптер меняет интерфейс существующего объекта. Декоратор улучшает другой объект без изменения его интерфейса. Причём Декоратор поддерживает рекурсивную вложенность, чего не скажешь об Адаптере.

  • Адаптер предоставляет классу альтернативный интерфейс. Декоратор предоставляет расширенный интерфейс. Заместитель предоставляет тот же интерфейс.

  • Цепочка обязанностей и Декоратор имеют очень похожие структуры. Оба паттерна базируются на принципе рекурсивного выполнения операции через серию связанных объектов. Но есть и несколько важных отличий.

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

  • Компоновщик и Декоратор имеют похожие структуры классов из-за того, что оба построены на рекурсивной вложенности. Она позволяет связать в одну структуру бесконечное количество объектов.

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

    Но они могут и сотрудничать: Компоновщик может использовать Декоратор, чтобы переопределить функции отдельных частей дерева компонентов.

  • Архитектура, построенная на Компоновщиках и Декораторах, часто может быть улучшена за счёт внедрения Прототипа. Он позволяет клонировать сложные структуры объектов, а не собирать их заново.

  • Стратегия меняет поведение объекта «изнутри», а Декоратор изменяет его «снаружи».

  • Декоратор и Заместитель имеют похожие структуры, но разные назначения. Они похожи тем, что оба построены на композиции и делегировании работы другому объекту. Паттерны отличаются тем, что Заместитель сам управляет жизнью сервисного объекта, а обёртывание Декораторов контролируется клиентом.

Реализация в различных языках программирования

Java