21 июня 2021
Паттерны проектирования
Структурные шаблоны
Паттерны отвечают за построение удобных в поддержке иерархий классов. Адаптер, мост, фасад, шаблон. Сегодня говорим о них.
Структурные паттерны проектирования

Эти паттерны отвечают за построение удобных в поддержке иерархий классов:

  • Адаптер
  • Мост
  • Фасад
  • Декоратор

Адаптер. Суть паттерна

Позволяет объектам с несовместимыми интерфейсами работать вместе.
Адаптер. Проблема.
Адаптер. Решение.
Адаптер. Структура.
Клиент – класс, который содержит существующую бизнес-логику программы.
Адаптер – класс, который может одновременно работать и с клиентом, и с сервисом. Он реализует клиентский интерфейс и содержит ссылку на объект сервиса.
Клиентский интерфейс – описывает протокол, через который клиент может работать с другими классами.
Сервис – класс, обычно сторонний. Клиент не может использовать этот класс напрямую, так как сервис имеет непонятный ему интерфейс.


Адаптер. Применимость.

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

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

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

Мост

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

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

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

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

      Преимущества:
      • Позволяет строить платформо-независимые программы.
      • Скрывает лишние или опасные детали реализации от клиентского кода.
      • Реализует принцип открытости/закрытости.

      Недостатки:
      • Усложняет код программы из-за введения дополнительных классов.

      Фасад.

      Предоставляет простой интерфейс к сложной системе классов, библиотеке или фреймворку.
      Фасад. Проблема.
      Фасад. Решение.
      Фасад. Структура.

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

      Фасад. Применимость.

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

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

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

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

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

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

      Недостатки:
      • Трудно конфигурировать многократно обёрнутые объекты.
      • Обилие крошечных классов.

      Заместитель.

      Позволяет подставлять вместо реальных объектов специальные объекты-заменители.
            Заместитель. Проблема.
                  Заместитель. Решение.
                        Заместитель. Структура.

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

                        Сервис – содержит полезную бизнес-логику.
                              Заместитель. Применимость.

                              • Ленивая инициализация. Например, когда у вас есть тяжёлый объект, грузящий данные из файловой системы или базы данных.
                              • Защита доступа. Когда в программе есть разные типы пользователей, и вам хочется защищать объект от неавторизованного доступа.
                              • Логирование запросов. Когда требуется хранить историю обращений к сервисному объекту.
                              • Кеширование объектов. Когда нужно кешировать результаты запросов клиентов и управлять их жизненным циклом.
                                    Заместитель. Преимущества и недостатки.

                                    Преимущества:
                                    • Позволяет контролировать сервисный объект незаметно для клиента.
                                    • Может работать, даже если сервисный объект ещё не создан.
                                    • Может контролировать жизненный цикл служебного объекта.
                                    Недостатки:
                                    • Усложняет код программы из-за введения дополнительных классов.
                                    • Увеличивает время отклика от сервиса.

                                          Вам также может быть интересно