Масштабная трансформация
Сбербанка в прямом эфире
LIVE

Перестаньте использовать операторы if-else

В закладки

Наверняка вы видели огромное количество уроков, в которых используются операторы if-else. Скорее всего вы прочитали множество книг, продвигающих использование if-else, а по сути техническое разветвление в программировании.

Возможно вы даже используете if-else по умолчанию, но давайте положим этому конец и заменим его объектами состояния.

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

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

Для тех, кто все еще в неведении, вот очень краткое вступление:

Вы будете усложнять читаемость кода с каждым новым условным требованием, реализованным с помощью If-Else.

Применяя шаблон состояний, вы просто изменяете поведение объектов, используя специализированные объекты состояний вместо операторов If-Else.

Прошли те дни, когда код выглядел так:

Вы, конечно, уже писали более сложные ветки. Уверен, что несколько лет назад.

Логика ветвления выше даже не очень сложна - но попробуйте добавить новые условия, и вы увидите, как эта штука взорвётся.

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

Еще лучше, это сделает вашу кодовую базу более солидной.

"Ладно, я убежден, что If-else - зло, а теперь покажите мне, как избежать кода разветвления”.

Мы рассмотрим, как я заменю If-Else ветвление в коде, готовом к производству. Это вымышленный пример, но этот подход я использовал, работая с крупными клиентами.

Давайте создадим очень простой Booking class, в котором есть пара состояний.Также у него будет два открытых метода: Accept( ) и Cancel( ).

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

Рефакторинг логики ветвления из нашего кода - это трехступенчатый процесс:

1.Создайте абстрактный базовый класс состояния

2.Реализуйте каждое состояние как отдельный класс, наследуемый от базового состояния.

3.Пусть класс "Booking" имеет частный или внутренний метод, который принимает в качестве параметра базовый класс состояния

Demo time.

Во-первых, нам нужен класс базового состояния, от которого унаследуют все состояния.

Обратите внимание, что в этом базовом классе также есть два метода, Accept и Cancel - хотя здесь они помечены как внутренние.

Кроме того, базовое состояние имеет "специальный" метод EnterState . Он вызывается всякий раз, когда объекту Booking присваивается новое состояние.

Во-вторых, мы делаем отдельные классы для каждого состояния, которое мы хотим представить.

Обратите внимание, что каждый класс представляет состояние, как описано на красивой диаграмме выше. Кроме того, CancelledState не позволит нашему резервированию перейти в новое состояние. Этот класс очень похож по духу на Null Object Pattern.

Наконец, сам класс Booking.

Видите, как класс Booking просто делегирует реализацию Accept and Cancel своему объекту состояния?

Это позволяет снять большую часть условной логики и позволяет каждому состоянию сосредоточиться только на том, что важно для него самого - текущее состояние также имеет возможность перевести booking в новое состояние.

Как справляться с новыми условными характеристиками?

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

Это так же просто. Вам больше не придется иметь дело с громоздкими операторами if-else.

Как сохранить объект состояния в базе данных?

Никак.

Объект состояния не важен при сохранении объекта, например, в базу данных SQL или NoSQL. Важно только знать состояние объекта и то, как он должен быть отображен в столбце.

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

Это много дополнительных классов!

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

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

Автор:Nicklas Millard.

Перевод:Федоров Матвей.

Еще больше полезной и нужной информации вы найдете в нашем Телеграм-канале по ссылке:

{ "author_name": "Fedorov Mathew", "author_type": "self", "tags": [], "comments": 7, "likes": -5, "favorites": 12, "is_advertisement": false, "subsite_label": "dev", "id": 141228, "is_wide": true, "is_ugc": true, "date": "Fri, 10 Jul 2020 17:24:00 +0300", "is_special": false }
Финансы
Венчурные инвестиции в ближайшем будущем
Замедление экономики вполне закономерно заставляет финансистов быть осторожнее, особенно в части рисковых…
Объявление на vc.ru
0
7 комментариев
Популярные
По порядку
Написать комментарий...
7

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

Впечатление на неопытных конечно производит и кодовая база действительно выглядит СОЛИДНОЙ, но людей с таким стремлением к усложнениям даже близко нельзя подпускать к реальным проектам )

Ответить
3

Иной раз 10 строчек кривого императивного кода, лучше 1000 строчек обмазанного OOD паттернами кода.

Ответить
1

Поддерживаю полностью! Встречались подобные проекты. Когда сидишь и втыкаешь во все это и почти слышишь голос автора этого чуда -"смотри как я могу. И вот тут ещё... И вот здесь."

Сорян. Нахлынуло

Ответить
4

Было бы лучше написать пример с букингом используя if-else, а потом переписать через state pattern, или еще лучше переписать первый пример кода, где есть price > 1000, тогда хотя бы можно было бы сравнить результат.

Ответить
3

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

Ответить
1

Чёт мне даже тот убогий пример с if-ами нравится больше!!! А ведь его можно ещё и написать более красиво!

Ответить
–1

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

Ответить

Комментарии