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

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

Основные проблемы, возникающие в коде, в котором не применяется техника защитных предложений, следующие:

  1. Чрезмерный отступ. Чрезмерное использование структуры управления, если она вложена, означает, что существует высокий уровень отступа, который затрудняет чтение кода.
  2. Взаимосвязь между if-else. Когда между if-else имеется большое количество отдельных фрагментов кода, которые концептуально связаны друг с другом, необходимо выполнять чтение кода, перескакивая между разными частями. .
  3. Мысленное усилие. Последствия различных скачков в исходном коде вызывают дополнительные усилия при генерации кода.

Итак, практическое применение оговорки о защите представляет собой следующий случай:

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

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

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

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

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

Представьте, что вам нужно создать метод для расчета стоимости медицинского страхования, в котором идентификатор пользователя принимается в качестве параметра.
Поиск в базе данных выполняется с использованием этого идентификатора для поиска пользователя. В случае, если пользователь не существует, будет сгенерировано исключение с именем UserNotFoundException. Если пользователь существует в системе, следующим шагом будет проверка того, что его медицинское страхование соответствует одному из тех, которые действительны для этого алгоритма: Allianz или AXA. Если страховка недействительна, необходимо вернуть исключение с именем UserInsuranceNotFoundException. Наконец, этот алгоритм действителен только для пользователей испанского гражданства. Поэтому вам следует еще раз проверить, является ли пользователь испанцем, чтобы выполнить расчет страховки или вернуть исключение под названием UserIsNotSpanishException.

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

Некоторые вопросы, которые необходимо решить:

  1. Почему нет случаев if-else if?
  2. Перестань думать! Если вашему коду требуются случаи вроде else if, это потому, что вы нарушаете принцип единой ответственности, и код принимает решения более высокого уровня, которые следует реорганизовать с использованием таких методов, как разделение на подметоды или шаблоны проектирования, такие как как команда или стратегия.
  3. Отрицательные условия не совсем понятны.
  4. Для этого у нас есть другой метод рефакторинга, называемый _ извлечение метода_, который заключается в извлечении кода в функции для повторного использования или для понимания прочитанного. В следующем примере мы изменили предыдущий пример, создав методы, которые позволяют лучше читать и понимать код.

При использовании clause guard логика условий обычно инвертируется, и, в зависимости от сложности условия, довольно сложно понять, что оценивается в этом условии.

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

Для нашего примера медицинского страхования мы можем сгенерировать следующие методы:

Нет необходимости создавать функцию для проверки, существует ли пользователь, поскольку достаточно просто проверить, что пользователь отличается от null или undefined. Следовательно, результирующий код будет следующим:

Есть много способов улучшить качество кода. Самое важное, что нужно усвоить при применении техник рефакторинга, - это то, что они должны быть сосредоточены на двух моментах, а именно:

  1. Разъединение кода, что позволяет небольшим изменениям не вызывать больших связанных изменений во всем проекте программного обеспечения.
  2. Читаемость, очень важно, чтобы разработчики понимали, что большая часть их работы основана на чтении кода и, вероятно, кода, написанного другим разработчиком. С точки зрения затрат / разработки очень выгодно, чтобы разработчик не тратил время на понимание элементарной логики, потому что ее нелегко прочитать.

Рефакторинг начинается с самого элементарного момента, простого «если», до архитектурного паттерна. Важно заботиться обо всех аспектах разработки нашего программного обеспечения.

Refactoring.com
Охранник - Википедия

Первоначально опубликовано на https://carloscaballero.io 31 мая 2019 г.