Паттерны проектирования. Структурные шаблоны.

21 июня 2021

Паттерны проектирования
Структурные шаблоны

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

Структурные паттерны проектирования

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

  • Адаптер
  • Мост
  • Фасад
  • Декоратор
Адаптер. Суть паттерна

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

Адаптер. Проблема.

Адаптер. Решение.

Адаптер. Структура.

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

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

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

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

Мост

Разделяет один или несколько классов на две отдельные иерархии — абстракцию и реализацию, позволяя изменять их независимо друг от друга.

Мост. Проблема.

Мост. Решение.

Мост. Структура.

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

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

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

      Преимущества:

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

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

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

      Фасад. Проблема.

      Фасад. Решение.

      Фасад. Структура.

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

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

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

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

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

      Декоратор. Проблема.

      Декоратор. Решение.

      Декоратор. Структура.

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

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

      Преимущества:

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

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

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

            Заместитель. Проблема.

                  Заместитель. Решение.

                        Заместитель. Структура.

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

                              Заместитель. Применимость.

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

                                    Преимущества:

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

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

                                          ⟵ Назад

                                          Смотрите также

                                          Архитектор, кто ты?

                                          Запуск тестов внутри контейнеров

                                          Марафон по нагрузочному тестированию: схема общих понятий

                                          Zabbix 5: сущность и принципы применения

                                          Тестирование приложений банковского и финансового секторов: примеры тестовых случаев

                                          Меняем мир сотового ритейла вместе с «Территория возможностей»

                                          НОУ ИНТУИТ | Лекция | Структурные шаблоны проектирования

                                          Аннотация: Данная глава нашей книги содержит описание наиболее «низкоуровневых» паттернов, описывающих структурные особенности создаваемых программных продуктов. Шаблоны структурного типа практически не содержат абстрактных описаний сложных компонентов. Они состоят из однозначных, понятных и простых элементов, которые являются наиболее оптимальным способом решения задачи разработки комплексных, высококачественных систем, как для разработчиков и группы поддержки, так и для конечных пользователей. Структурные паттерны являются одним из базисных элементов сферы шаблонов проектирования. С их применением создаются более сложные, уже рассмотренные нами архитектурные и интеграционные паттерны. Книга организована постепенным снижением с уровня более абстрактных понятий к специализированным. Это позволит читателю взглянуть на картину в целом и выделить для себя наиболее значимые аспекты в дальнейшем развитии и обучении. Именно поэтому данная глава является связующим звеном при переходе между уровнями абстракции.

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

                                          Введение

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

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

                                          Подробно рассмотрим 10 наиболее значимых шаблонов, изучение которых сформирует необходимый базис и позволит постепенно кристаллизовать информацию о паттернах проектирования у читателей, запутанных архитектурными и интеграционными шаблонами.

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

                                          Шаблоны структуры объектов

                                          В качестве структурных паттернов проектирования сегодня мы рассмотрим следующие:

                                          intuit.ru/2010/edi»>»Адаптер», «Декоратор», «Заместитель», «Информационный эксперт», «Компоновщик», «Мост», «Низкая связанность», «Приспособленец», «Устойчивый к изменениям», «Фасад».

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

                                          Адаптер

                                          Структурный шаблон «Адаптер» востребован в ситуации, когда необходимо организовать использование функций определенного бизнес-объекта, недоступного для модификации.

                                          Это происходит, когда система или ее компонент имеют требуемые данные и функциональность, но не имеют подходящего интерфейса.

                                          Если сформулировать его назначение иначе, то шаблон «Адаптер» обеспечивает взаимодействие несовместимых интерфейсов путем предоставления единого устойчивого интерфейса для нескольких компонентов.

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

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

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

                                          Это шаблон общего характера и очень часто используется в комбинации с другими шаблонами проектирования.

                                          «Банда четырех» (основная группа евангелисты объектно-ориентированного подхода к разработке программного обеспечения) следующим образом определяет назначение паттерна»Адаптер»:

                                          «Преобразование исходного интерфейса класса в интерфейс, более подходящий для конкретных нужд. Применение этого шаблона позволяет организовать совместную работу несовместимых интерфейсов».

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

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

                                          На сегодняшний момент распространены два типа этого шаблона:

                                          • intuit.ru/2010/edi»> Объектный. Вариант шаблона, реализуемый посредством помещения, адаптируемого в другой, адаптирующий объект.
                                          • Классовый. Использует механизм множественного наследования и получил название классового.

                                          Выбор варианта определяется спецификой проблемной области.

                                          Шаблон «Адаптер» можно сравнить с электрическим переходником, необходимым для подключения «евро» -вилок с цилиндрическими наконечниками к азиатским розеткам.

                                          Рис. 5.2.1. Шаблон «Адаптер»

                                          Декоратор

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

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

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

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

                                          «Декоратор» позволяет реализовать большую гибкость, чем у статического наследования, создаваемого путем разработки подклассов.

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

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

                                          Заместитель

                                          В случаях, когда необходимо управлять доступом к объекту, так чтобы создавать громоздкие компоненты только «по требованию», оптимально использовать шаблон «Заместитель».

                                          Суть «Заместителя» состоит в том, что он хранит ссылку, которая позволяет ему обратиться к реальному субъекту только при необходимости, задействуя системные ресурсы.

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

                                          Шаблон «Заместитель» может иметь и другие обязанности:

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

                                          Шаблон «Заместитель» достаточно часто используют в паре с шаблоном «Адаптер».

                                          Информационный эксперт

                                          Когда в системе должна аккумулироваться, преобразовываться и удаляться необходимая информация, применяется шаблон «Информационный эксперт».

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

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

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

                                          Что такое структурный образец? (Определение)

                                          Урок 2 Что такое структурный паттерн?
                                          Цель Определение структурных моделей.

                                          Шаблон структурного проектирования служит планом того, как различные классы и объекты объединяются для формирования более крупных структур. В отличие от созидательных паттернов , которые в основном представляют собой разные способы достижения одной и той же фундаментальной цели, каждый структурный паттерн имеет свою цель.
                                          Вопрос: Что объединяет структурные модели?
                                          Ответ: Все они включают связи между объектами.
                                          В некотором смысле структурные шаблоны подобны более простой концепции структур данных.
                                          Однако шаблоны структурного проектирования также определяют методы, которые соединяют объекты, а не просто ссылки между ними. Кроме того, структуры данных являются довольно статичными сущностями. Они лишь описывают, как данные расположены в структуре. А 9Шаблон структурного проектирования 0017 также описывает, как данные перемещаются по шаблону.
                                          Шаблоны структурных классов используют наследование для объединения интерфейсов или реализаций нескольких классов. Структурные классовые паттерны относительно редки.
                                          Шаблоны структурных объектов используют композицию объектов для объединения реализаций нескольких объектов. Они могут объединять интерфейсы всех составных объектов в один унифицированный интерфейс или предоставлять совершенно новый интерфейс.

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


                                          Структурные шаблоны описывают, как классы и объекты могут быть объединены в более крупные структуры. Разница между шаблонами классов и шаблонами объектов заключается в том, что шаблоны классов описывают, как можно использовать наследование для предоставления более полезных программных интерфейсов.
                                          Шаблоны объектов описывают, как объекты могут быть составлены в более крупные структуры с использованием композиции объектов или включения объектов в другие объекты.
                                          Например, мы увидим, что Шаблон адаптера можно использовать для согласования одного интерфейса класса с другим, чтобы упростить программирование. Мы также рассмотрим ряд других структурных шаблонов, в которых мы комбинируем объекты для обеспечения новой функциональности. Композит именно такой:
                                          «Композиция объектов, каждый из которых может быть либо простым, либо составным объектом».
                                          Шаблон Proxy часто представляет собой простой объект, который принимает место более сложного объекта, который может быть вызван позже, например, когда программа запускается в сетевой среде. Модель наилегчайшего веса — это шаблон для совместного использования объектов, где каждый экземпляр не содержит собственного состояния, а хранит его извне. Это позволяет эффективно совместно использовать объекты для экономии места, когда существует много экземпляров, но только несколько разных типов.
                                          Шаблон Фасад используется для того, чтобы один класс представлял весь подсистема, а шаблон Bridge отделяет интерфейс объекта от его реализации, поэтому вы можете изменять их по отдельности. Наконец, шаблон Decorator можно использовать для динамического добавления обязанностей к объектам.


                                          Классификация шаблонов проектирования Часть 2 — Структурный шаблон | Авелон Панг | Nerd For Tech

                                          Опубликовано в

                                          ·

                                          7 мин чтения

                                          ·

                                          25 мая 2021 г.

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

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

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

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

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

                                          Pros

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

                                          Минусы

                                          • Сложность кода увеличивается с каждым новым интерфейсом и классом, который вы вводите в свой код.

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

                                          Pros

                                          • Принцип единой ответственности — фокус на высокоуровневой логике в абстракции
                                          • Принцип открытости/закрытости — внедрить новую абстракцию и реализации независимо друг от друга
                                          • Создать независимые от платформы классы

                                          Минусы

                                          • Возможность усложнить код путем применения шаблона к высоко связанному классу

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

                                          Плюсы

                                          • Принцип открытости/закрытости — введение новых типов элементов без нарушения существующего кода
                                          • Используйте полиморфизм и рекурсию в своих интересах 35
                                            • Может быть сложно обеспечить общий интерфейс для классы, когда функциональные возможности сильно различаются
                                            • Возможность чрезмерного обобщения интерфейса компонента для двух разных интерфейсов может затруднить его понимание

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

                                            Pros

                                            • Принцип единой ответственности — разделение монолитного класса, реализующего множество возможных вариантов поведения, на меньшие классы поведение без создания новый подкласс
                                            • Добавление или удаление обязанностей объекта во время выполнения

                                            Минусы

                                            • Удаление определенной оболочки из стека оберток может вызвать затруднения
                                            • Начальный код конфигурации слоев может выглядеть неприятно.
                                            • Сложно реализовать декоратор без его поведения, зависящего от порядка стека декораторов. Шаблон прокси контролирует доступ к исходному объекту, позволяя вам выполнять какие-либо действия либо до, либо после прохождения запроса к исходному объекту. Другими словами, этот шаблон контролирует и управляет доступом к объекту, который они проецируют. Есть много ситуаций, когда следует рассмотреть дизайн прокси. Например, когда вы хотите, чтобы только определенные клиенты могли использовать объект службы, хотите сохранить историю или запросы к объекту службы или должны иметь возможность отклонять тяжеловесный объект, когда нет клиентов, которые его используют.

                                              Pros

                                              • Принцип Open/Closed
                                              • Не зависит от готовности или доступности сервисного объекта для его работы
                                              • Управление жизненным циклом сервисного объекта, когда клиент не заботится об этом 9 0089
                                              • Управление сервисным объектом без ведома клиентов

                                              Минусы

                                              • Высокий риск усложнения кода с каждым введением нового класса
                                              • Вероятность задержки ответа от сервиса
                                              Оператор выступает в качестве фасада для всех служб и отделов компании

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

                                              Плюсы

                                              • Изоляция вашего кода от сложности подсистемы

                                              Минусы

                                              • Возможность превращения фасада в объект God (объект, который слишком много знает или слишком много делает) на все классы приложения.

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

                                              No related posts.