Что такое шаблон разработки стратегии?
Шаблон разработки стратегии - это шаблон проектирования поведения. Это испытанный и проверенный способ разработки кода, который можно использовать в сценариях, где нам нужно выбрать конкретный подход (алгоритм) из пула доступных связанных подходов во время выполнения для достижения что-то.
Этот шаблон проектирования также иногда называют шаблоном политики.
В этой статье давайте рассмотрим практический сценарий использования этого шаблона проектирования и напишем код на Java, чтобы получить практическое представление.
Сценарий:
Предположим, что у нас есть вымышленное приложение, которое содержит несколько классных статей и соответствующие им URL (вспомните, может быть, Hackernews?).
вы создали это приложение с единственной целью - делиться интересными статьями. теперь, пока вы в туалете, вас осенила довольно захватывающая идея. Что, если бы у вас была функция, в которой ваши пользователи могли бы делиться ссылками на эти статьи со своими контактами в различных социальных сетях? в конце концов, в наши дни каждое приложение и его мать имеют эту функцию.
Прочитав пару документов API различных приложений для социальных сетей, вы быстро поймете, что не все API общего доступа к социальным сетям созданы одинаково. вздох :(
Итак, теперь мы находимся в точке, где у нас есть множество методов для обмена контентом, и мы должны выбрать один в зависимости от приложения социальной сети, выбранного пользователем (по сути, во время выполнения). Вам это почему-то кажется знакомым, потому что это ситуация из учебника по использованию шаблона стратегии по определению.
Подход:
Первым шагом в создании архитектуры кода в соответствии с шаблоном разработки стратегии является объявление политики или стратегии (семейства алгоритмов). В нашем случае это будут шаги, которые нам потребуются для обмена ссылками.
Что может быть лучше для создания контракта или политики, чем использование интерфейса? Итак, мы нажимаем на клавиатуру и разрабатываем интерфейс SocialActions следующим образом:
Интерфейс / Политика:
Адаптеры:
Теперь, когда мы определили семейство (которое называется «Совместное использование»), нам нужно создать пул алгоритмов.
В нашем случае алгоритм совместного использования зависит от платформы, на которой он будет использоваться. Таким образом, мы абстрагируем реализацию алгоритма совместного использования для каждой платформы в ее собственных соответствующих классах адаптеров. Таким образом, нашему приложению в любое время приходится иметь дело только с одним методом общего доступа с заранее определенной подписью.
Для простоты и демонстрации паттерна проектирования давайте просто будем вести журналы консоли в этих вариантах алгоритмов совместного использования вместо того, чтобы фактически реализовывать механизмы совместного использования.
Класс контекста:
Теперь у нас есть четыре различных алгоритма обмена на выбор, и пришло время создать способ упростить процесс выбора во время выполнения для нашего приложения, создав уровень абстракции и предоставив согласованный и предсказуемый метод обмена URL-адресами.
Это не только делает наш код чище, но и делает процесс обслуживания менее кошмарным.
Использование:
Наконец, давайте посмотрим на пример использования кода, который мы уже создали:
Результат приведенного выше примера кода драйвера будет следующим:
Заключительные мысли:
Таким образом, мы разработали систему, которая выбирает соответствующий механизм совместного использования во время выполнения из пула доступных алгоритмов совместного использования, используя шаблон разработки стратегии.
Преимущества этого дизайна заключаются в том, что мы можем расширять систему, не изменяя ее (вспомните Open-Close в принципе S.O.L.I.D?). Что мы имеем в виду? ты спрашиваешь. Скажем, через месяц после запуска этой функции в производство вы обнаружите, что большая часть ваших пользователей использует Instagram и хотели бы, чтобы это тоже было опцией. На этом этапе все, что вам нужно сделать, это создать адаптер для Instagram и покончить с этим. Простое расширение, приятное обслуживание :)
Преимущество № 2, ваши адаптеры изолированы и могут быть легко протестированы. Также разделение этих деталей реализации делает имитацию прогулки по парку во время модульного тестирования.
Преимущество номер 3: в этом дизайне, если вы внимательно посмотрите, мы намеренно уменьшили наследование, насколько это возможно. Завтра изменение спецификации может быть легко связано с техникой композиции.
Надеюсь, вы нашли это полезным, и спасибо, что прочитали мои мысли.
Ваше здоровье :)