Файл: уфимский университет науки и технологий факультет математики и информационных технологий кафедра программирования и экономической информатики.docx
Добавлен: 10.11.2023
Просмотров: 175
Скачиваний: 8
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Минусы
-
Увеличение сложности посредника: Посредник может стать сложным объектом, особенно если в системе присутствуют множество объектов и сложные взаимосвязи между ними. Это может привести к усложнению паттерна и увеличению его сложности и поддержки. -
Односторонняя коммуникация: В некоторых случаях использование посредника может привести к тому, что объекты потеряют возможность взаимодействовать напрямую, что может быть неэффективным в определенных ситуациях.
Пример
Чат-приложения: В многопользовательских чат-приложениях посредник может использоваться для передачи сообщений между участниками чата. Вместо прямого обмена сообщениями между пользователями, они отправляют сообщения посреднику, который затем передает их нужным получателям.
-
Хранитель (Memento)
Хранитель (Memento) - это паттерн проектирования, который позволяет сохранять и восстанавливать внутреннее состояние объекта без нарушения инкапсуляции. Хранитель представляет собой объект, который хранит снимок состояния другого объекта, а затем может восстановить его в будущем.
Плюсы
-
Позволяет сохранять и восстанавливать состояние объекта, не нарушая его инкапсуляцию. -
Упрощает процесс сохранения и восстановления состояния объекта. -
Позволяет сохранять различные версии состояния объекта и возвращаться к ним при необходимости. -
Облегчает реализацию отката операций или отмены изменений.
Минусы
-
Паттерн может потребовать дополнительного использования памяти для хранения состояния объекта, особенно если состояние объекта является большим или сложным. -
Взаимодействие между Издателем, Хранителем и Хранителем может стать сложным и требовать тщательного управления.
Пример
-
Редакторы текста или графические редакторы, где можно сохранять состояние документа и восстанавливать его при необходимости.
-
Наблюдатель (Observer)
Наблюдатель (Observer) - это паттерн проектирования, который обеспечивает механизм уведомления об изменении состояния объекта другим объектам, которые заинтересованы в этом изменении. В паттерне Наблюдатель есть один издатель (также называемый субъектом или наблюдаемым объектом) и несколько наблюдателей, которые подписываются на изменения издателя и автоматически получают уведомления о них.
Плюсы
-
Разделение ответственностей: Паттерн Наблюдатель позволяет разделить логику обновления состояния и реакции на изменения состояния между издателем и наблюдателями. Это способствует более гибкой и поддерживаемой архитектуре. -
Расширяемость: Наблюдатель легко расширяется новыми наблюдателями без изменения кода издателя. Это позволяет гибко добавлять и удалять наблюдателей в системе. -
Гибкая связь: Издатель и наблюдатели связаны через абстрактный интерфейс, что позволяет им работать вместе, не зависимо от конкретных реализаций.
Минусы
-
Наблюдатели могут быть независимыми друг от друга, что может привести к необходимости поддерживать консистентность состояния между ними. -
Издателю требуется дополнительная логика для управления наблюдателями и отправки им уведомлений, что может усложнить код и увеличить сложность понимания.
Пример
Блоги и социальные сети: Веб-приложения для блогов и социальных сетей могут использовать паттерн Наблюдатель для уведомления подписчиков о новых сообщениях, комментариях или активности других пользователей. Издателем может быть автор блога или пользователь, а подписчики - наблюдателями, получающими уведомления.
-
Посетитель (Visitor)
Посетитель — поведенческий шаблон проектирования, описывающий операцию, которая выполняется над объектами других классов. При изменении visitor нет необходимости изменять обслуживаемые классы.
Пример из жизни: Туристы собрались в Дубай. Сначала им нужен способ попасть туда (виза). После прибытия они будут посещать любую часть города, не спрашивая разрешения ходить где вздумается. Просто скажите им о каком-нибудь месте — и туристы могут там побывать. Шаблон посетитель помогает добавлять места для посещения.
Простыми словами: Шаблон посетитель позволяет добавлять будущие операции для объектов без их модифицирования.
Плюсы использования паттерна «Посетитель»:
-
Расширяемость. Позволяет добавлять новые операции, не изменяя классы элементов. -
Отделение алгоритмов от структуры объектов. Это облегчает поддержку и повторное использование кода. -
Упрощение добавления новых классов элементов. Для добавления нового класса элемента достаточно реализовать метод accept в новом классе.
Минусы использования паттерна «Посетитель»:
-
Усложнение структуры программы. Введение интерфейса «Посетитель» и реализация методов accept в классах элементов требуют дополнительного кода, что может привести к усложнению архитектуры. -
Нарушение инкапсуляции. Паттерн позволяет обращаться к приватным членам элементов через методы посетителя, что может нарушить принципы инкапсуляции.
Пример
Туристы собрались в Дубай. Сначала им нужен способ попасть туда (виза). После прибытия они будут посещать любую часть города, не спрашивая разрешения ходить где вздумается. Просто скажите им о каком-нибудь месте — и туристы могут там побывать. Шаблон посетитель помогает добавлять места для посещения.
-
стратегия (Strategy)
Стратегия — поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путём определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.
Простыми словами: Шаблон стратегия позволяет переключаться между алгоритмами или стратегиями в зависимости от ситуации.
Плюсы использования паттерна "Стратегия":
-
Гибкость и расширяемость: Паттерн "Стратегия" позволяет заменять алгоритмы независимо от кода клиентов. Это обеспечивает гибкость и расширяемость системы, поскольку новые алгоритмы могут быть добавлены без изменения существующего кода. -
Избегание дублирования кода: Паттерн "Стратегия" позволяет избежать дублирования кода, связанного с различными вариантами алгоритмов. Каждый алгоритм инкапсулируется в отдельном классе, что устраняет необходимость повторного написания кода. -
Улучшение читаемости и поддержки кода: Код, использующий паттерн "Стратегия", становится более читаемым и легко поддерживаемым. Каждый алгоритм находится в отдельном классе, что делает его легко понять и изменить при необходимости. -
Упрощение тестирования: Паттерн "Стратегия" облегчает тестирование системы, поскольку каждый алгоритм может быть протестирован независимо от других. Это позволяет более эффективно выявлять и исправлять ошибки.
Минусы использования паттерна "Стратегия":
-
Усложнение конфигурации системы: При наличии большого числа стратегий может возникнуть сложность в конфигурации системы для выбора конкретной стратегии. Это может потребовать дополнительных механизмов для определения и управления выбором стратегии. -
Повышенная сложность понимания кода: Паттерн "Стратегия" может привести к увеличению сложности понимания кода, особенно для разработчиков, незнакомых с паттерном. Разделение логики на различные классы и взаимодействие между ними может усложнить анализ и отладку кода. -
Затраты на создание и поддержку классов стратегий: Каждый алгоритм требует свой собственный класс стратегии. Создание и поддержка таких классов может быть затратным в плане времени и ресурсов. Кроме того, необходимо обеспечить согласованность интерфейсов стратегий и клиентского кода. -
Недостаточная гибкость в случае изменения алгоритмов: Паттерн "Стратегия" предоставляет гибкость в замене алгоритмов, но может стать сложным, если требуется изменить сам интерфейс стратегии. Если изменения затрагивают существующие интерфейсы, это может потребовать модификации клиентского кода и всех соответствующих стратегий.
Пример
Рассмотрим ситуацию, где у нас есть сервис доставки, который предлагает несколько вариантов доставки: наземную доставку, авиадоставку и морскую доставку. Каждый из этих вариантов имеет свои особенности, стоимость и время доставки.
В этом случае мы можем применить паттерн "Стратегия". Создадим абстрактный класс "Стратегия доставки" с методом "доставить", который будет реализован в конкретных стратегиях доставки: "Наземная доставка", "Авиадоставка" и "Морская доставка".
Клиент, который хочет отправить товар, будет иметь возможность выбрать одну из стратегий доставки в зависимости от своих требований. Например, если клиенту важно получить товар быстро, он выберет авиадоставку, а если ему важно сэкономить деньги, он может выбрать наземную доставку.
Когда клиент выбирает стратегию доставки и вызывает метод "доставить", соответствующая стратегия будет выполнена. Каждая стратегия будет иметь свою собственную реализацию алгоритма доставки, учитывающую особенности выбранного способа доставки.
Применение паттерна "Стратегия" в этом случае позволяет достичь гибкости и расширяемости системы доставки. Если в будущем появятся новые способы доставки, их можно будет легко добавить, создав новую стратегию доставки, не затрагивая существующий код клиента.
3.9. состояние (State)
Состояние — поведенческий шаблон проектирования. Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния.
Простыми словами: Шаблон позволяет менять поведение класса при изменении состояния.
Плюсы использования паттерна "Состояние":
-
Разделение поведения и состояния: Паттерн "Состояние" позволяет явно разделить поведение объекта от его состояния. Каждое состояние реализуется в отдельном классе, что упрощает добавление новых состояний и изменение поведения объекта без изменения его структуры. -
Устранение условных операторов: Паттерн "Состояние" позволяет заменить условные операторы, которые определяют поведение объекта в зависимости от его состояния, полиморфными вызовами методов. Это делает код более читаемым, легко поддерживаемым и расширяемым. -
Гибкость и расширяемость: Паттерн "Состояние" обеспечивает гибкость и расширяемость системы, позволяя добавлять новые состояния без изменения существующего кода. Это позволяет легко добавлять новые поведения и состояния в систему и управлять их взаимодействием. -
Улучшение тестируемости: Каждое состояние может быть протестировано независимо от других состояний, что упрощает тестирование и отладку системы. Тестирование каждого состояния отдельно позволяет более точно выявлять и исправлять ошибки.