Введение в шаблон стратегии | https://codewithshabib.com
При разработке программного обеспечения в реальной жизни мы постоянно сталкиваемся с проблемой, связанной с изменением требований. Любой, кто участвует в бизнес-игре программного обеспечения, знает, как часто и радикально спецификации программного обеспечения могут меняться в любое время. По этой причине в разработке программного обеспечения неизменной считается только одна вещь: ИЗМЕНЕНИЕ!
В объектно-ориентированном мире у нас есть несколько хороших способов справиться с этим, например, шаблоны проектирования. Существует множество шаблонов проектирования, которые могут помочь нам, разработчикам. Среди них наиболее распространенным и широко используемым является шаблон стратегии. Любой разработчик с несколькими годами опыта за плечами использует это довольно часто (иногда даже не подозревая об этом!).
В этом посте я попытаюсь создать сценарий, который мы можем решить, используя шаблон стратегии.
Предположим, что мы в софтверной компании BadAss Softwares Inc, где мы создаем несколько отличных программ. Теперь наш клиент, г-н Биг Босс, хочет сделать программное обеспечение для умной машины. Его первоначальные требования просты:
- Я хочу умную машину.
- Он может водить.
- Оно может говорить.
Выполнить это требование, как считает наш звездный разработчик Джонни Доу, очень просто! Итак, он пишет следующий код.
Мистер Биг счастлив, он получил то, что просил. И мы тоже счастливы. Но теперь приходит вызов; кто-то подал мистеру Бигу идею, зачем только водить машину и говорить. Это чертовски умный автомобиль, он должен стремиться к большему! Итак, г-н Биг меняет это требование на следующее:
- Да, я хочу умную машину, которая может делать все предыдущие вещи.
- Я хочу еще одну супер умную машину, она должна ездить не только по дороге, но и по воде! (Ну, не смейся!)
Теперь Джонни умный. Ему нравится повторно использовать как можно больше частей кода. Итак, как бы он это спроектировал? А вот и наш милый друг Наследство! Итак, Джони создает подкласс SmartCar и добавляет новый метод driveOnWater. Круто, не правда ли?
Теперь мы снова осчастливили Мистера Бига! Как это круто!
Но у мистера Бига есть нечто большее, теперь он хочет сделать умный автомобиль, который может не только ехать по дороге, но и летать (но не может ехать по воде)! Теперь у Джонни небольшие проблемы, так как он не может просто создать еще один подкласс для поддержки этого. Как бы он справился с этим вопросом? Ну, как я уже сказал, Джонни умен! Он знает что-то под названием Интерфейс, отличный инструмент в ООП (который в нашем случае в Swift известен как протокол)! Так, как «езда по дороге» и другие черты общие, кроме «езды по воде». Он создает протокол с именем Flyable и создает еще один подкласс SmartCar.
Теперь у нас есть SmartCar, SuperSmartCar и FlyingSmartCar, которые могут бегать по дороге и разговаривать с вами! Мистер Биг доволен, наша компания довольна, а Джонни получил солидный бонус! Но хорошие дни не длятся долго. Из-за сложных функций автомобили мистера Бига не так хорошо зарекомендовали себя на рынке, поскольку людям это не нравится. Итак, мистер Биг проводит общественный опрос и выясняет, что людям не нужны все машины, они хотят машину, которая ездит по дороге, лодку, которая едет по воде, и самолет, который летает в воздухе. Итак, он снова звонит в нашу фирму и снова меняет требование:
- Я хочу умные машины.
- Я хочу умную машину, которая ездит по дорогам.
- Я хочу умную лодку, которая ходит по воде.
- Я хочу умный самолет, который летает.
- Эти умные автомобили должны отвечать.
Теперь Джонни в бешенстве, потому что ему нужно многое изменить и многое переделать. Поэтому он сидит с чашкой кофе и думает, как ему развязать все классы и внести изменения с наименьшими хлопотами. Джонни находит следующие вещи:
- Все продукты являются транспортными средствами и могут обмениваться сообщениями, поэтому он может написать класс транспортных средств с этой опцией.
- Автомобиль может говорить и бегать по дороге, но не может летать или бегать по воде.
- Лодка может говорить и бегать по воде, но не может летать или бегать по дороге.
- Самолет может говорить и летать, но не может бегать по воде или дороге.
Теперь, когда Джонни узнал, что клиент может изменить требование в любое время, он также думает о следующем:
- Что, если мистеру Бигу понадобится другой автомобиль, который снова сможет ездить как по воде, так и по дороге?
- Что, если мистеру Бигу понадобится еще одно транспортное средство, способное летать и ездить по дорогам?
- Что, если мистеру Бигу нужен другой автомобиль, который может делать все это?
Итак, теперь, чтобы ответить на эти вопросы, Джонни делает следующее:
- Создает отдельные классы путем создания подкласса класса Vehicle, что гарантирует, что все транспортные средства умны и могут общаться.
- Делает все поведения при запуске интерфейсами/протоколами, чтобы убедиться, что если возникнут какие-либо дополнительные изменения требований, ему нужно только реализовать протокол, чтобы обеспечить поддержку этой функции.
Теперь это последний код Джонни.
Теперь снова все счастливы, а Джонни получает еще один жирный бонус!
Шесть месяцев спустя г-н Биг решает, что рынок изменился, и людям снова нужны многофункциональные автомобили, поэтому он просит нашу компанию снова предоставить ему SmartCarBoat. Теперь у Джонни нет проблем с этим, потому что все, что ему нужно сделать, это реализовать протоколы!
С этой стратегией под рукой, независимо от того, сколько раз мистер Биг изменит свое требование, Джонни может убить его в любое время!
Надеюсь, мне удалось дать представление о том, как работает шаблон стратегии и как его использовать в сценарии реального времени. Конечно, мы можем улучшить это, используя другие способы; Я даю вам подсказку: абстрактный класс. Любые вопросы, отзывы или если вы думаете, что у меня есть некоторые улучшения, не стесняйтесь комментировать!
Удачного кодирования! 😁
Первоначально опубликовано на сайте codewithshabib.com 5 февраля 2017 г.
