Делая первые шаги в изучении программирования, многие новички сталкиваются с ветвлением и начинают писать длинные вложенные циклы.
К примеру, возьмем ситуацию, когда нам нужно дать пользователю доступ к кошельку (isAccess()).
Мы вводим следующие две проверки:
1) Пользователь залогинен
2) Пользователь идентифицирован
За проверки у нас отвечает результат методов isLogin() и isIdentify(). Они возвращают логические true или false.
РАЗРАБОТЧИК И МАКАРОННАЯ ФАБРИКА
Да, ничего сложного в задаче нет. Пишем проверки, если прошла первая проверка (isLogin()) - движемся ко второй(isIdentify()). Если все проверки прошли успешно - даем доступ к кошельку(isAccess()). Вот как обычно это выглядит у новичков:
Мы получили вложенные проверки. Сейчас у нас всего две проверки, а если их четыре, пять или более? У кода с такой архитектурой есть жирный минус - его неудобно читать, в нём бывает сложно разобраться.
БУДЬ ПРОЩЕ
Перед нами стоит задача написать код проще и понятнее. Как это сделать? Да как два байта переслать 😉.
Необходимо избавиться от вложенных проверок, заменив их проверками с противоположными условиями. В Java для этого есть специальный логический оператор НЕ (!)(логическое отрицание). Он меняет логическое значение операнда с истины на ложь и наоборот.
Смысл наших действий в том, чтобы прописать не условия, когда нужно что-то делать, а условия, когда чего-то ДЕЛАТЬ НЕ НУЖНО и стоит завершить программу. Т.е., мы пишем своеобразный фейсконтроль, если входные данные условиями не вышли - мы сразу же завершаем программу.
Обычно это делается следующим образом:
1) В условии проверки меняют значение на противоположное с помощью логического оператора (!).
2) Если это условие выполняется (т.е. мы получили неподходящие входные данные), то программа сразу же останавливается.
3) Все ранее вложенные друг в друга условия делают невложенными и размещают друг под другом.
Перепишем наш код:
Теперь наша логика работает следующим образом:
1) Пользователь не залогинен? Выходим из функции.
2) Пользователь не идентифицирован? Выходим из функции.
3) Даем достум тем, кто не вышел на всех предыдущих этапах.
Таким образом мы получаем:
1) Код стало легче читать.
2) В код можно легко внести новые проверки или убрать ненужные.
Как видим, немного изменив код, мы сделали его более понятным и чистым. А значит, стали еще ближе к качественному коду.
Но, на всякий случай помним: "Хорошо задокументированный баг, автоматически становится фичей!"
Спасибо за внимание!
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ