Эта статья не подтверждает и не опровергает способ написания, а только предлагает вам некоторые другие идеи кодирования или некоторые идеи, заслуживающие внимания.
5 способов разработать лучшее программное обеспечение, заменив if-else, от новичков до продвинутых примеров
If-Else, как правило, плохой выбор, он приводит к сложному дизайну, плохой читаемости кода и может привести к сложному рефакторингу.
Тем не менее, If-Else стал де-факто решением для ветвления кода, что имеет смысл. Это первое, чему учат всех начинающих разработчиков.
К сожалению, многие разработчики никогда не переходят к более подходящей стратегии ветвления. У некоторых людей есть мантра: Если-иначе — это молоток, то все — гвозди.
Я собираюсь показать вам несколько советов и моделей, которые положат конец этой ужасной практике. Сложность возрастает с каждым примером.
Совершенно ненужный блок Else
Это, пожалуй, одно из самых преступных преступлений младших разработчиков. Следующий пример — хороший пример того, что происходит, когда вы думаете, что If-Else — это круто:
Simple if-else
Это можно упростить, просто удалив блок else`, как показано ниже:
Removed else
Выглядит более профессионально, не так ли? Вы обнаружите, что никакие другие блоки на самом деле не нужны. Как и в этом случае, вы хотите что-то сделать и немедленно вернуться, если будет выполнено определенное условие.
распределение стоимости
Если вы присваиваете новое значение переменной на основе некоторого предоставленного ввода, прекратите дерьмо If-Else, более читаемый подход.
Value assignment with if-else
Как бы просто это ни было, это отстой. Во-первых, здесь If-Else можно легко заменить переключателем. Однако мы можем еще больше упростить этот код, полностью удалив else.
If statements with fast return
Если мы не используем else, у нас остается чистый, читаемый код. Обратите внимание, что я также изменил стиль на быстрый возврат вместо одного оператора возврата. Нет смысла продолжать проверку значения, если правильное значение уже найдено.
Предварительная проверка
В общем, я обнаружил, что нет смысла продолжать, если метод предоставляет недопустимое значение. Предположим, у нас есть метод DefineGender из предыдущего, который требует, чтобы предоставленное входное значение всегда было 0 или 1.
Method without value checks
Нет смысла выполнять метод без проверки значения. Поэтому нам нужно проверить некоторые предварительные условия, прежде чем разрешить выполнение метода.
Применяя технику защитного кодирования с помощью защитных предложений, вы проверите входные значения метода, а затем приступите к выполнению метода.
Check preconditions with guard clauses
На этом этапе мы убедились, что основная логика выполняется только в том случае, если значение попадает в ожидаемый диапазон. Теперь IF также был заменен троичным, так как больше не нужно возвращать «неизвестно» по умолчанию в конце.
Преобразование If-Else в словарь, полностью избегайте If-Else
Допустим, вам нужно выполнить какие-то действия, которые будут выбраны исходя из каких-то условий, и мы знаем, что позже нужно будет добавить больше действий.
Может быть, кто-то склонен использовать проверенный и надежный If-Else. Если вы добавляете новое действие, вы можете просто добавить что-то еще. Простой.Однако этот подход не является хорошим дизайном с точки зрения обслуживания.
Зная, что позже нам нужно будет добавить новые операции, мы можем преобразовать If-Else в словарь.
Удобочитаемость значительно улучшилась, а код стало легче расшифровывать. Обратите внимание, что словарь помещен внутри метода только в иллюстративных целях. Вы можете предоставить его из другого места.
Расширьте свое приложение и полностью избегайте If-Else
Вот немного более сложный пример. Знайте, когда даже полностью исключить «если», заменив их объектами.
Часто вам придется расширять части вашего приложения. Как младший разработчик, у вас может возникнуть соблазн сделать это, добавив дополнительный оператор If-Else (также известный как else-if).
Возьмем этот наглядный пример. Здесь нам нужно отобразить экземпляр Order в виде строки. Во-первых, у нас есть только два строковых представления: JSON и обычный текст.
Использование If-Else на этом этапе не имеет большого значения, если мы можем легко заменить другие, если это уже упоминалось.
Зная, что нам нужно расширить эту часть приложения, такой подход абсолютно неприемлем.
Вышеприведенный код не только нарушает принцип «открыто/закрыто», но и плохо читается и вызывает проблемы с ремонтопригодностью.
Правильный подход — это тот, который следует принципам SOLID, и мы делаем это, реализуя процесс обнаружения динамического типа (в данном случае — шаблон стратегии).
Процесс рефакторинга этого запутанного процесса выглядит следующим образом:
- Извлеките каждую ветвь в отдельный класс политики, используя общий интерфейс.
- Динамически находит все классы, реализующие общий интерфейс.
- Решите, какую стратегию выполнять на основе входных данных.
Код для замены приведенного выше примера показан ниже. Да, это способ больше кода. Это требует от вас понимания того, как работает обнаружение типов. Но динамическое масштабирование приложений — это сложная тема.
Я показываю только ту часть примера, которая заменит If-Else. Ознакомьтесь с этим содержанием, если вы хотите увидеть все задействованные объекты.
Давайте быстро взглянем на код. Сигнатура метода остается прежней, потому что вызывающей стороне не нужно знать о нашем рефакторинге.
Во-первых, получите все типы в сборке, реализующие универсальный интерфейс IOrderOutputStrategy. Затем мы создаем словарь с отображаемым именем средства форматирования в качестве ключа и типом в качестве значения.
Затем выберите тип средства форматирования из словаря и попытайтесь создать экземпляр объекта политики. Наконец, вызовите ConvertOrderToString объекта политики.