Чем заменить if else

Альтернатива if/else и switch: литералы объектов в JavaScript

Авторизуйтесь

Альтернатива if/else и switch: литералы объектов в JavaScript

Сложные условия в JS всегда были источником лишнего кода. Однако использование литералов объектов в JavaScript может избавить вас от этой проблемы. Давайте разберёмся, как это работает.

Литерал объекта в JavaScript — это список пар ключ-значение, перечисленных через запятую и обёрнутый фигурными скобками.

Допустим у нас есть функция, которая принимает на вход рифмованную фразу на английском сленге кокни и возвращает её значение. Если использовать конструкцию if/else, то код будет выглядеть следующим образом:

Выглядит так себе. Этот код не только плохо читается, но и использует повторяющийся вызов функции toLowerCase().

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

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

Альтернатива

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

Мы используем объект, ключи которого выполняют роль условий, а значения — результатов. Затем, с помощью квадратных скобок, мы проверяем наличие нужной строки. Так как полученная строка может быть null или undefined, то мы используем оператор Nullish coalescing (??). Таким образом мы избавляемся от null-значения, но не исключаем случай, что результат может быть равен нулю или false.

Подробнее о способах обработки undefined в JavaScript.

Сложная логика

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

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

Вывод

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

Источник

Как заменить многие операторы if в Java

Изучите различные способы замены сложных вложенных операторов if

1. Обзор

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

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

2. Тематическое исследование

Мы также можем реализовать это с помощью switch statements :

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

3. Рефакторинг

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

3.1. Заводской класс

Метод принимает два числа в качестве входных данных и возвращает результат. Давайте определим класс для выполнения дополнений:

Теперь мы реализуем фабричный класс, который возвращает экземпляры Operation на основе данного оператора:

Теперь в классе Calculator мы можем запросить завод, чтобы получить соответствующую операцию и применить исходные номера:

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

3.2. Использование перечислений

Давайте посмотрим, как мы можем этого достичь. Сначала нам нужно определить наше Перечисление :

Мы определим методы для каждого из значений Enum и выполним расчет. Например:

А затем в классе Calculator мы можем определить метод для выполнения операции:

Теперь мы можем вызвать метод путем преобразования String значения в Оператор с помощью Operator#valueOf() метод :

3.3. Шаблон команд

Сначала мы определим наш Командный интерфейс:

Далее, давайте реализуем команду Add:

Затем мы можем вызвать вычисление, создав экземпляр команды Add и отправив ее в метод Calculator#calculate :

3.4. Механизм правил

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

Во-вторых, давайте реализуем Механизм правил :

Теперь мы вызовем механизм правил с выражением |:

4. Заключение

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

Источник

❗ Удалите из кода If-Else и Switch Case

Перевод публикуется с сокращениями, автор оригинальной статьи Nicklas Millard.

C корее всего, i f- e lse и switch – ваш обычный подход к ветвлению кода, но в нем нет необходимости. Вы можете полностью исключить ключевое слово else из своего словаря по программированию. Некоторые матерые кодеры говорят, что i f-else – полиморфизм новичков.

Что плохого в традиционном ветвлении?

Много чего. Традиционное ветвление быстро разрастается. Вам придется изменять существующий код каждый раз при добавлении новой функции. Это нарушает принцип Open-Closed. Функции должны быть реализованы с помощью новых классов.

Какие есть альтернативы?

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

Эти 3 подхода легко справятся с большинством повседневных ситуаций, с которыми вы можете столкнуться.

Все методы имеют общие черты:

Моделирование концепций с помощью простых классов

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

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

Гораздо лучшим подходом является перенос концепции имени пользователя и создание небольшого специализированного объекта, как показано ниже.

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

Изменение реализации метода объекта в зависимости от его состояния

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

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

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

Видите, какая плоская конструкция?

Удвойте количество кода и повысьте читабельность.

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

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

Рефакторинг ветвлений на отдельные классы

Наиболее часто используемый способ устранения условных ветвлений – объекты стратегии.

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

Мы можем сделать это, разделив каждую ветку switch/case на специализированные классы, что делает enum ненужным.

Рассмотрим приведенный ниже код:

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

Представьте, как легко сейчас протестировать и исправить ошибки. Вы всегда будете точно знать, что проверять и где искать. Больше никаких следов безумной switch-логики.

Заключение

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

Источник

Программное обеспечение без конструкции if-else

Jul 19, 2020 · 5 min read

Не откладывая в долгий ящик скажу: зачастую конструкция if-else — плохой выбор. Её использование приводит к сложным конструкциям, снижает читаемость кода и усложняет рефакторинг.

Тем не менее, конструкция if-else де-факто стала решением для ветвления кода, что имеет смысл. Это одна из первых тем, которую изучают начинающие разработчики. К несчастью, многие так никогда и не переходят на более подходящие стратегии ветвления.

Некоторые живут по правилу: if-else молоток, всё остальное — гвозди.

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

Я продемонстрирую несколько приёмов и шаблонов, которые помогут положить конец этой неприятной практике. Сложность будет возрастать с каждым примером.

1. Совсем лишние блоки else

Это с а мая распространённая ошибка начинающих разработчиков. Ниже яркий пример того, как вы проигрываете, используя if-else:

Выражение легко упростить, просто убрав блок else :

Источник

Как избавиться от if-else при помощи команд и обработчиков

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

Рассматриваемый в статье способ — просто один из многих.

Сама по себе конструкция if-else не так уж плоха. Мы просто попали в ситуацию «когда в руках молоток, всё вокруг кажется гвоздями». В основах программирования мы изучаем условные операторы и многим разработчикам не удаётся перерасти их использование.

Однако if-else и switch зачастую неидеальны. Программисты обычно пренебрегают более качественными решениями, например, полиморфическим исполнением и словарями.

Мы стремимся избегать традиционного условного ветвления

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

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

Сложное ветвление, вызывающее головную боль

Кроме уродливого использования if-elseif-else основная проблема заключается в том, что нужно добавлять ветвление для каждой новой причины обновления. Это явное нарушение принципов открытости/закрытости и единственной ответственности.

По сути, каждую ветвь можно преобразовать в собственную команду и соответствующие обработчики.

Давайте посмотрим, как это возможно.

Использование команд и обработчиков для упрощения приложения

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

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

Наконец-то код!

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

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

Существует три критерия, которые нам нужно удовлетворить:

Начнём с самого внешнего слоя и дойдём до самого дна

Если смотреть не с точки зрения контроллера, то нам не важно знать конкретные обработчики и даже интерфейсы. Действие должно быть сосредоточено только на данных.

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

Обновление конечной точки электронной почты

Примерный смысл кода должен быть вам понятен, хоть это и C# aspnetcore. Если вкратце, это действие контроллера — конечная точка и её реализация.

Я знаю, о чём вы думаете: «а где обработка ошибок?» Не волнуйтесь, вы правы, она должна здесь быть, но ради краткости я вырезал её, чтобы можно было сосредоточиться на концепции выполнения команд.

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

Каждая «причина обновления» (update reason) требует собственной конечной точки со своей формой данных, то есть отправляемой командой.

На этом этапе для реализации новых функций, например «update username», достаточно создать новую конечную точку и отправить команду.

Конечная точка Update username

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

По сути, наша конечная точка уже готова.

Итак, давайте двигаться дальше.

В командах и обработчиках находится вся бизнес-логика

При работе с командами нам нужно заботиться о двух аспектах: неизменяемости и корректности данных.

Старый добрый класс команды

Очевидно, что этот класс команды выполняет не очень много действий. В этом-то и весь смысл. Его задача — передаваться обработчику.

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

Простой обработчик команды, который легко тестировать.

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

Вы ощущаете, насколько удобен для тестирования этот класс? В этом весь смысл. Его ужасно легко будет тестировать. Этот класс очень сфокусирован — один метод, одна зависимость.

Если вы привыкли к классам «Service», то знаете, какими безумными иногда становятся конструкторы. Такой подход полностью устраняет возможность разбухания конструктора.

Сам диспетчер, невероятно простой и надёжный

Вы уже видели интерфейс диспетчера, он понятен и прост. Но давайте освежим воспоминания.

Публичный интерфейс диспетчера команды

Мы хотим сказать: «вот команда, найди все соответствующие ей обработчики и передай команду каждому из них».

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

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

Диспетчер команды с поиском по словарю

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

Сам код в описании не нуждается. Это обычный C#. Важно только его назначение.

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

Затем вызывается каждый обработчик.

Вот и всё. Это довольно просто.

Соединяем это всё с обнаружением динамических типов

На самом деле, на данном этапе ещё ничего не работает.

Нам нужно передать где-нибудь Dictionary диспетчеру команды.

В идеале нужно создать диспетчер команды и его словарь где-нибудь при запуске приложения и зарегистрировать его при помощи фреймворка внедрения зависимостей.

Помните наш третий критерий? Новые функции/требования не должны требовать изменения существующего кода.

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

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

У нас снова есть код на C#, который совершенно не относится к делу, но, возможно, покажется кому-то интересным.

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

Обнаружение динамических типов при запуске программы

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

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

Я писал код таким образом намеренно. Естественно, чтобы он был более приятным, нужно было бы провести рефакторинг с извлечением методов. Однако для демонстрации это вполне приемлемо.

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

На правах рекламы

Эпичные серверы — это VPS на Windows или Linux с мощными процессорами семейства AMD EPYC и очень быстрыми NVMe дисками Intel. Спешите заказать!

Источник