Что такое шаблон разработки стратегии?

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

Этот шаблон проектирования также иногда называют шаблоном политики.

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

Сценарий:

Предположим, что у нас есть вымышленное приложение, которое содержит несколько классных статей и соответствующие им URL (вспомните, может быть, Hackernews?).

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

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

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

Подход:

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

Что может быть лучше для создания контракта или политики, чем использование интерфейса? Итак, мы нажимаем на клавиатуру и разрабатываем интерфейс SocialActions следующим образом:

Интерфейс / Политика:

Адаптеры:

Теперь, когда мы определили семейство (которое называется «Совместное использование»), нам нужно создать пул алгоритмов.

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

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

Класс контекста:

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

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

Использование:

Наконец, давайте посмотрим на пример использования кода, который мы уже создали:

Результат приведенного выше примера кода драйвера будет следующим:

Заключительные мысли:

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

Преимущества этого дизайна заключаются в том, что мы можем расширять систему, не изменяя ее (вспомните Open-Close в принципе S.O.L.I.D?). Что мы имеем в виду? ты спрашиваешь. Скажем, через месяц после запуска этой функции в производство вы обнаружите, что большая часть ваших пользователей использует Instagram и хотели бы, чтобы это тоже было опцией. На этом этапе все, что вам нужно сделать, это создать адаптер для Instagram и покончить с этим. Простое расширение, приятное обслуживание :)

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

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

Надеюсь, вы нашли это полезным, и спасибо, что прочитали мои мысли.

Ваше здоровье :)