В компьютерном программировании сторож - это логическое выражение, которое должно быть истинным, если выполнение программы должно продолжаться в рассматриваемой ветви.
Независимо от того, какой язык программирования используется, защитный код или защитное предложение - это предварительные условия проверки целостности, используемые для предотвращения ошибок во время выполнения. - Википедия
Основные проблемы, возникающие в коде, в котором не применяется техника защитных предложений, следующие:
- Чрезмерный отступ. Чрезмерное использование структуры управления, если она вложена, означает, что существует высокий уровень отступа, который затрудняет чтение кода.
- Взаимосвязь между if-else. Когда между if-else имеется большое количество отдельных фрагментов кода, которые концептуально связаны друг с другом, необходимо выполнять чтение кода, перескакивая между разными частями. .
- Мысленное усилие. Последствия различных скачков в исходном коде вызывают дополнительные усилия при генерации кода.
Итак, практическое применение оговорки о защите представляет собой следующий случай:
В этом случае и в большинстве случаев вы должны изменить логику, чтобы избежать использования зарезервированного слова else
. Предыдущий код будет переписан следующим образом:
Следовательно, частные случаи, которые вызывают выход из метода, будут помещены в начало метода и будут действовать в качестве защитных средств таким образом, чтобы избежать продолжения удовлетворительного выполнения метода.
Таким образом, метод легко читается, поскольку конкретные случаи находятся в начале одного и того же, а случай удовлетворительного использования потока - это основа метода.
Есть недоброжелатели оговорок о защите, которые указывают, что в каждом методе должна быть только одна точка выхода, и с помощью этого метода мы находим несколько точек выхода. Его не следует путать с возвращением повсюду и без контроля наших методов, которые заставят нас приложить еще большие умственные усилия. Но все возвраты четко контролируются, так как они будут найдены у охранников или в конце метода.
Ниже мы увидим примеры более сложных защитных предложений, в которых чтение и понимание кода значительно улучшены.
Представьте, что вам нужно создать метод для расчета стоимости медицинского страхования, в котором идентификатор пользователя принимается в качестве параметра.
Поиск в базе данных выполняется с использованием этого идентификатора для поиска пользователя. В случае, если пользователь не существует, будет сгенерировано исключение с именем UserNotFoundException
. Если пользователь существует в системе, следующим шагом будет проверка того, что его медицинское страхование соответствует одному из тех, которые действительны для этого алгоритма: Allianz или AXA. Если страховка недействительна, необходимо вернуть исключение с именем UserInsuranceNotFoundException
. Наконец, этот алгоритм действителен только для пользователей испанского гражданства. Поэтому вам следует еще раз проверить, является ли пользователь испанцем, чтобы выполнить расчет страховки или вернуть исключение под названием UserIsNotSpanishException
.
Как видите, в коде много уровней отступов. Та же версия предыдущего алгоритма показана ниже, но была применена техника защитных предложений. Этот метод позволяет сделать код более читаемым. Обратите внимание, что были применены 3 защитных предложения, которые позволяют генерировать альтернативные пути (выбросить исключения), которые не влияют на результат алгоритма.
Некоторые вопросы, которые необходимо решить:
- Почему нет случаев
if-else if
? - Перестань думать! Если вашему коду требуются случаи вроде
else if
, это потому, что вы нарушаете принцип единой ответственности, и код принимает решения более высокого уровня, которые следует реорганизовать с использованием таких методов, как разделение на подметоды или шаблоны проектирования, такие как как команда или стратегия. - Отрицательные условия не совсем понятны.
- Для этого у нас есть другой метод рефакторинга, называемый _ извлечение метода_, который заключается в извлечении кода в функции для повторного использования или для понимания прочитанного. В следующем примере мы изменили предыдущий пример, создав методы, которые позволяют лучше читать и понимать код.
При использовании clause guard логика условий обычно инвертируется, и, в зависимости от сложности условия, довольно сложно понять, что оценивается в этом условии.
Вот почему хорошей практикой является извлечение логики условий в небольших функциях, которые позволяют повысить читаемость кода и, конечно же, находить в них ошибки, поскольку ответственность за оценку условия делегируется конкретной функции.
Для нашего примера медицинского страхования мы можем сгенерировать следующие методы:
Нет необходимости создавать функцию для проверки, существует ли пользователь, поскольку достаточно просто проверить, что пользователь отличается от null или undefined. Следовательно, результирующий код будет следующим:
Есть много способов улучшить качество кода. Самое важное, что нужно усвоить при применении техник рефакторинга, - это то, что они должны быть сосредоточены на двух моментах, а именно:
- Разъединение кода, что позволяет небольшим изменениям не вызывать больших связанных изменений во всем проекте программного обеспечения.
- Читаемость, очень важно, чтобы разработчики понимали, что большая часть их работы основана на чтении кода и, вероятно, кода, написанного другим разработчиком. С точки зрения затрат / разработки очень выгодно, чтобы разработчик не тратил время на понимание элементарной логики, потому что ее нелегко прочитать.
Рефакторинг начинается с самого элементарного момента, простого «если», до архитектурного паттерна. Важно заботиться обо всех аспектах разработки нашего программного обеспечения.
Refactoring.com
Охранник - Википедия
Первоначально опубликовано на https://carloscaballero.io 31 мая 2019 г.