Switch (Case) всегда ошибается?
Есть ли случаи, когда переключатель (case) - это хороший выбор дизайна (за исключением простоты) по сравнению со стратегией или аналогичными шаблонами ...
Ответы 8
Во-первых, читабельность.
Классы с осмысленными именами и методами с осмысленными именами гораздо более читабельны для других программистов, чем анонимные блоки, которые необходимо дублировать, потому что они вложены внутри переключателей или где-то еще, чтобы быть справедливым. Если утверждения так же плохи.
Обычно это нормально, если у вас есть только переключатель один в месте один. когда у вас их несколько (или несколько), самое время подумать об альтернативах.
«Стратегии» могут быть созданы переключателем.
Это может быть отправной точкой, и оттуда пусть полиморфизм сделает свою работу.
Другое, что приходит на ум, требует дополнительной скорости за счет гибкости. Есть случаи.
Да, безусловно. Часто ваш переключатель имеет отношение только к очень небольшой части вашей общей логики, и было бы ошибкой создавать целые новые классы только для этого второстепенного эффекта.
Например, предположим, что у вас есть база данных слов, пользователь вводит другое слово, и вы хотите найти это слово в базе данных, но включить возможные множественные числа. Вы можете написать что-нибудь вроде (C++)
vector<string> possible_forms;
possible_forms.push_back(word);
char last_letter = word[word.size() - 1];
switch (last_letter) {
case 's':
case 'i':
case 'z':
possible_forms.push_back(word + "es");
break;
case 'y':
possible_forms.push_back(word.substr(0, word.size() - 1) + "ies");
break;
default:
possible_forms.push_back(word + "s");
}
Делать это с помощью стратегий было бы излишним.
А как насчет «человек», «овца» или слов, которые уже во множественном числе? Множественность является частью типа данного слова. С полиморфизмом у нас все в порядке, мы можем добавить их позже без изменения кода. С переключателем вы должны модифицировать и расширять свой код. В английском языке так много правил, что я не удивлюсь, если «незначительный эффект» вышеприведенного переключения перерастет в «серьезную проблему обслуживания», состоящую из более чем 1000 строк. Я видел одиночные переключатели в чужом коде почти на 3000 строк задолго до этого. Так что нет, всегда есть лучший выбор, чем использование переключателя.
В настоящее время этот код состоит из 15 строк. Если кто-то другой переписывает его в более 1000 строк, сохраняя при этом один оператор switch, это его ошибка, а не ошибка исходного оператора switch.
Прежде всего, простота часто является хорошим выбором для дизайна.
Я никогда не понимал этого предубеждения против переключателя / корпуса. Да, им можно злоупотреблять, но то же самое можно сказать и о любой другой программной конструкции.
Включение типа обычно неверно и, вероятно, должно быть заменено полиморфизмом. Обычно нормально включать другие вещи.
Переключатели выбирают поведение - следовательно, подразумевается, что задействован поведенческий тип, то есть все, что включается, «есть» или «имеет» набор различимых типов, в противном случае было бы невозможно использовать переключатель. Поэтому мы всегда включаем тип, и я согласен с вами, что включение типа «неправильно» (в том смысле, что сложно поддерживать и повторно использовать поведение).
Нет, оператор switch, вероятно, является хорошим выбором дизайна только в простых ситуациях.
Как только вы пройдете простую ситуацию, операторы switch станут очень болезненно обновлять и поддерживать. Это одна из причин появления шаблонов проектирования.
Используйте переключатели, когда вы тестируете значения примитивов. (т.е. целые числа или символы).
Используйте полиморфизм, когда выбираете между разными типы.
Примеры : Проверка того, является ли введенный пользователем символ одним из символов «a», «b» или «c», является задачей переключателя.
Проверка того, является ли объект, с которым вы имеете дело, собакой или кошкой, является задачей полиморфной отправки.
На многих языках, если у вас есть более сложные значения, вы все равно не сможете использовать Switch.
Переключатели всегда связаны с поведенческим типом, потому что они выбирают поведение. У ценностей нет поведения. Пользователь не ввел «a», «b» или «c», он сделал выбор, и поведение программы зависит от типа этого выбора. Нажатая ими клавиша была просто временной ссылкой для этого типа, так же как указатель может ссылаться на класс. Полиморфизм был бы более ясным способом смоделировать это.
Я считаю, что переключатель всегда неправильный:
Тело кейса - это код и поведение является, следовательно, вещь в футляре («значение») имеет поведенческий тип, поэтому полиморфизм был бы лучшим выбором.
Это означает, что значения на самом деле являются типами, например число 1 - это тип всего, что в некотором роде равно 1. Все, что нам остается, - это сопоставить единичность с поведением для нашего конкретного случая, и у нас есть полиморфизм со всеми этими типами (Хорошая вещь).
Это легче сделать на некоторых языках, чем на других, к сожалению, большинство широко используемых языков довольно ужасны, поэтому путь наименьшего сопротивления - неправильный, и люди в конечном итоге пишут переключатели или операторы if (одно и то же).
В Perl это
given/when