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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Никак.

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

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

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

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

Автор:Nicklas Millard.

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

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

https://t.me/metsolution