Достаточно ли сложен мой код для использования оператора switch в Swift?

Из документации Swift:

Typically, you use the if statement to evaluate simple conditions with only a few possible outcomes. The switch statement is better suited to more complex conditions with multiple possible permutations and is useful in situations where pattern matching can help select an appropriate code branch to execute.

Я пытаюсь решить, следует ли мне использовать переключатель или операторы if/else в зависимости от того, есть ли у меня сложное условие. Так что у меня вопрос, мое состояние сложное или нет.

Вот пример того, что у меня есть:

var sampleVar = Measurement(value: amount, unit: UnitLength.megameters)

if (type == "inches"){
     //do something
}
else if...

У меня есть от 5 до 15 возможных условий, которые я проверяю, поэтому будет ли это достаточно сложным, чтобы оправдать использование оператора switch? Или сложность основана на условии, а не на количестве условий?

Чтобы уточнить, вы просто проверяете 5-15 различных возможных значений «типа»? Если да, то это звучит как типичный вариант использования switch. Но, в конечном счете, правильный ответ — это то, что вам легче читать и поддерживать.

John Montgomery 07.06.2019 21:27

Правильно, я просто проверяю 5-15 возможных значений типа. Спасибо за ответ! Я думаю, что Switch легче читать, поэтому я пойду с ним.

Brian Phair 07.06.2019 21:29

Строка "inches" — это запах кода. Вероятно, вам следует использовать полиморфизм или, как минимум, перечисления или словари. smartflow.wordpress.com/2015/04/20/code-smell-stringly-typed

Alexander 07.06.2019 21:36

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

Gereon 07.06.2019 21:36

Никогда не слышал о "запахе кода" или "строчном коде". Спасибо за ответы, узнал что-то новое.

Brian Phair 08.06.2019 01:11
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
5
134
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Окончательный тест — просто записать оба и сравнить.

Когда switch лучше

Когда вы имеете дело с ситуацией, которая предпочитает switch лестнице if/else, ваш код будет выглядеть так:


if something == 1 {
    foo()
} else if something == 2 {
    bar()
} else if something == 3 {
    baz()
} else { 
    quux()
}

Как видите, все скобки, повторяющиеся ключевые слова (else, if), повторяющиеся операторы == и повторяющиеся экземпляры одного и того же идентификатора (something) добавляют кучу шума с очень небольшой ценностью. Сравните с switch:

switch something {
    case 1: foo()
    case 2: bar()
    case 3: baz()
    default: quux()
}

Когда if/else if/else лучше

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

switch something {
    case 1: foo()
    case _ where case2_1() || case2_2(): bar()
    case _ where case3(): baz()
    case _ where case4(): quux()
}

против.

if something == 1 || case1() { foo() }
else if case2_1() || case2_2() { bar() }
else if case3() { baz() }
else if case4() { quux() }

Не забывайте о полиморфизме!

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

Другие вопросы по теме