Когда использовать оператор переключения в Java
Я ценю, что что-либо, что может быть сделано переключателем statment, еще может быть сделано если оператор.
Но есть ли стилистические правила для того, когда еще нужно использовать переключатель, а не если statment.
14 ответов
Ну, Switch чувствует себя «легче» во многих случаях, чем , если / / , если лестница, на мой взгляд. В основном у вас нет столько синтаксиса с брекетами и скобками в пути вашего кода. То, что говорится, выключатель наследует синтаксис C. Это означает, что у вас есть разрыв и только один объем для переменных, если вы не введете новые блоки.
Тем не менее, компилятор способен оптимизировать выключатели выключателей в таблицу поиска и выполнить проверку времени для литералов при работе с перечислениями. Таким образом, я бы предположил, чтобы он обычно предпочтительнее использовать , если / / / / ELS , если вы имеете дело с числовыми типами или Enum.
переключатель имеет два соответствующих недостатка:
- он ограничен примитивным типом и врачом
- , которые вы должны помнить » Перерыв », что может привести к не настолько очевидным ошибкам
, часто переключатель - это знак для плохого дизайна OO, потому что вам лучше использовать полиморфизм.
Единственное возможное преимущество переключателя является, что он более читаемый. Но это
switch (i) {
case 1:
// do something
break;
case 2:
// do something
break;
}
более читаемо, чем это:
if (i == 1)
//do something
else if (i == 2)
// do something else
Я бы сказал: нет! И у вас не было бы недостатков коммутатора.
Мое предложение: старайтесь избегать переключения.
Как и с другими языками, такими как C или C ++, операторы переключения полезны, когда вы хотите сравнить данную переменную со списком возможных значений и выполните действие в зависимости от этих значений. Это Терзер, чем если бы иначе заявления.
< script language = «JavaScript» type = «text/javascript» src = «http://www.example.com/hello.js» >
Данные добавляются в файл hello.js в виде массива, JSON или аналогичного файла. Пример: var daysInMonth = new Array (31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);
Получение JavaScript с другого сервера не намного проще..: -)
-121--2205950-Я бы сказал, что хорошо использовать VARCHAR как ПЕРВИЧНЫЙ и ВНЕШНИЙ КЛЮЧИ .
Единственная проблема, которую я мог бы оставить, это если у вас есть таблица, скажем Инструменты (инструменты обмена) и вы создаете PRIMARY/FOREIGN KEY как VARCHAR , и случается, что CODE изменяется.
Это происходит на фондовых биржах и требует переименования всех ссылок на CODE , где в качестве идентификатора nr это не требуется.
В заключение я бы сказал, что это зависит от вашего предполагаемого использования.
EDIT
Когда я говорю КОД, я имею в виду код бегущей строки, например GOOG, или любую другую акцию. Эти коды могут меняться с течением времени, скажем, вы посмотрите на инструменты Dirivative/Future.
-121--2520366-Может быть, немного оффтопически, но если бы я ответил только на вопрос в заголовке, то я бы сказал, что вы не должны использовать переключатель во всех ситуациях, когда случаи представляют состояния какого-то объекта. В этих случаях образец государства является гораздо более красивым решением.
Если у вас слишком много условий, чтобы проверить аналогичный тип, вы можете перейти на переключатель.
Выключатель и переключатель.
Если значение enum вы испытываете тестирование, может законно быть NULL по любой причине, вкладывая его в оператор выключателя, будет генерировать NullPointexception. Не глядя на байтовый код, это рода сбой, что это будет так.
Объяснение: Enums являются синтаксическим сахаром, введенным в 1,5. Заявление выключателя все еще работает с хорошими OLE int, но значения, которые он использует, являются орналами, назначаемыми к Enum. Для того, чтобы получить порядковый номер, значение Enum должно быть ненулевым.
Если заявление , с другой стороны, будет рад принять NULL для значения enum и просто отказуется от теста без NPE.
Прежде всего, оператор выключателя должен быть использован. Если переключатель основан на значении переменной, то он может быть использован. Если он основан на сложном и / или / не булевом выражении, который варьируется для каждого условия, то вы не можете использовать его вообще.
Это говорит, если оно применимо, и есть как минимум 2 случая, то я использую коммутатор. Легко ударяется, легче читать и проверять.
Я использую выключатели переключателей для Enums, более читаемо, что A, если иначе, если иначе, если операторы. Однако вы должны попытаться избежать таких проверок в дизайне OO.
Переключатель имеет одно преимущество, когда речь идет о ясности:
switch (i) {
case 1:
// do something
break;
case 2:
case 4:
// do something
break;
case 5:
// do something
break;
}
Если код для 2 и 4 идентичен, он может быть более прозрачным, чем:
if ( i == 1 ) {
// do something
}
if ( (i == 2) || (i == 4) ) {
// do something
}
if ( (i == 5 ) {
// do something
}
, также проще для вас (или другого программиста), чтобы разделить 2 и 4 случаи.
Лично, я использую, чтобы найти обоих конструкций слишком много процедур. Несмотря на то, что он может рассматриваться как OO Extermism, я использую для использования карты, содержащей экземпляры внутреннего интерфейса для каждого случаях IF. Это позволяет лучше изоляцию кода, я думаю. Тем не менее, для того, чтобы трельно ответить на ваш вопрос, я использую только коммутаторы, когда у меня есть случаи, которые действительно совпадают (я не использую операторы разрыва). К сожалению, это действительно не поддерживаемый код кода.
Вы используете оператор выключателя при включении различных значений типов примитивных / enum / Wrapper. (И не все типы примитивных / обертки, просто поддерживаемые - байт, короткие, CHAR, INT).
Если / остальные обрабатывают остальные.
Например, это более эстетически приятно сказать:
int i = getValueOfI();
switch (i) {
case 1:
// do something
break;
case 2:
// do something
break;
и т. Д.
чем
if (i == 1) {
} else if (i == 2) {
}...
для большого количества случаев. Но вы не можете включать строки или значения функций или сложные условия, поэтому, если вам нужно сделать любой из этого, вы застряли, если / else.
Я бы предложил простое правило:
Всегда используйте переключатель , когда у вас есть как минимум 2 опции для различения, когда тип данных используется для переключателя и когда все опции имеют постоянные значения.
На это есть три веские причины. Во-первых, в большинстве случаев переключатель / работает быстрее, чем каскад , если //. Во-вторых, это делает замысел кода более ясным. В-третьих, о так плохо забытая дилемма break является меньшим злом, чем огромный if/// каскады, которые случайно ломаются из-за того, что кто-то забыл /.
Java VM на самом деле поддерживают два разных типа коммутаторов: Tablewitch и lookupswitch. Компилятор генерирует tablewitch, если все case константы лежат в узком диапазоне, в противном случае он генерирует lookupswitch. Для больших операторов switch во многих случаях tablewitch более эффективен, чем lookupswitch. Поисковый выключатель обычно реализуется с помощью какой-то формы двоичного поиска.
Я всегда находил, что оператор switch в java не настолько мощный, как мне нужно. В своем последнем релизе lambdaj реализует его с умным использованием closure и Hamcrest matcher.
Например, lambdaj Switcher позволяет реализовать паттерн стратегии. Предположим, вам нужно переключаться между тремя алгоритмами сортировки на основе некоторой характеристики сортируемого списка. В частности, предположим, что у нас есть алгоритм, специализированный для строк:
public List<String> sortStrings(List<String> list) {
// a sort algorithm suitable for Strings
}
другой, который хорошо работает с небольшими списками, не превышающими 100 элементов:
public List<T> sortSmallList(List<T> list) {
// a sort algorithm suitable for no more than 100 items
}
и более универсальный:
public List<String> sort(List<String> list) {
// a generic sort algorithm
}
Учитывая эти 3 метода сортировки, можно создать стратегию, которая выбирает наиболее подходящий из них следующим декларативным образом:
Switcher<List<T>> sortStrategy = new Switcher<List<T>>()
.addCase(having(on(List.class).get(0), instanceOf(String.class))),
new Closure() {{ of(this).sortStrings(var(List.class)); }})
.addCase(having(on(List.class).size(), lessThan(100))),
new Closure() {{ of(this).sortSmallList(var(List.class)); }})
.setDefault(new Closure() {{ of(this).sort(var(List.class)); }});
и отсортировать список, используя лучший из доступных алгоритмов, вызвав Switcher:
List<T> sortedList = sortStrategy.exec(list, list);