Стратегия - шаблон поведенческого дизайна

Шаблоны проектирования

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

В этой статье мы рассмотрим один из наиболее понятных и широко используемых паттернов поведенческого проектирования под названием «Стратегия». Мы будем пытаться наивно решать бизнес-задачу и постепенно улучшать код с учетом возможности повторного использования и расширяемости.

Бизнес-проблема

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

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

Проверяется тип предупреждения и предпринимаются необходимые действия. Как вы думаете, есть ли проблема с приведенным выше кодом? Давайте рассмотрим то, что может быть неправильным.

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

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

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

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

Что мы можем сделать, чтобы навести порядок в этом беспорядке? Здесь нам на помощь приходит шаблон стратегии.

Решение - Стратегия

Если вы внимательно посмотрите на приведенный выше код, можно заметить, что есть две сущности. Один объект, который решает, кому делегировать вызов (код, содержащий блок if-else), и другой объект, который инкапсулирует алгоритм - шаги для фактической отправки уведомления на разные конечные точки.

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

Выше представлена ​​UML-диаграмма разделенной логики. Класс Context полагается на интерфейс Notification, который предоставляет sendMessage метод. Уведомление определяет семейство аналогичных алгоритмов отправки уведомления. Например: - Slack, электронная почта, SMS и т. Д.

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

Давайте реализуем приведенную выше диаграмму UML и посмотрим, как выглядит наш код.

Из приведенного выше кода видно, что мы можем легко подключить новый уведомитель к клиенту, реализовав интерфейс Уведомление. Во время выполнения стратегия уведомления устанавливается в контексте в зависимости от типа предупреждения.

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

Согласно принципу открытость-закрытие, классы должны быть открытыми для расширения и закрытыми для модификации. Не касаясь контекста, можно вводить новые стратегии, тем самым делая код расширяемым и многократно используемым.

Минусы стратегии

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

📝 Прочтите этот рассказ позже в Журнале.

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