Вводная
Как разработчики, мы каждый день сталкиваемся с кодом и чем больше того, который приходится нам по душе, мы видим, пишем, тем большим энтузиазмом проникаемся, тем более продуктивными и эффективными становимся. Да что там говорить, мы просто гордимся нашим кодом. Но одна дилемма не дает мне покоя: когда 2 разработчика смотрят на один и тот же код они могут испытывать совершенно противоположные чувства. И что делать, если эти чувства, эмоции, навеянные его эстетической красотой, не совпадает с эмоциями большинства окружающих Вас профессионалов? В общем, история о том, почему может не нравиться языковая конструкция switch на столько, что предпочитаешь if. Кому интересна эта холиварная позиция добро пожаловать под кат.
Немного нюансов
Речь ниже пойдет о сравнении оператора switch и его конкретной реализаций на языке Java и операторами if в виде оппонентов этой конструкции. О том, что у оператора switch имеется туз в рукаве — производительность (за редким исключением), пожалуй, знает каждый и этот момент рассматриваться не будет — так как крыть его нечем. Но все же, что не так?
1. Многословность и громоздкость
Среди причин, отталкивающих меня от использования оператора switch — это многословность и громоздкость самой конструкции, только взгляните — switch, case, break и default, причем опускаю за скобки, что между ними, наверняка, еще встретится return и throw. Не подумайте, что призываю не использовать служебные слова языка java или избегать их большого количества в коде, нет, лишь считаю, что простые вещи не должны быть многословными. Вот небольшой пример того, о чем говорю:
public List<String> getTypes1(Channel channel) {
switch (channel) {
case INTERNET:
return Arrays.asList("SMS", "MAC");
case HOME_PHONE:
case DEVICE_PHONE:
return Arrays.asList("CHECK_LIST");
default:
throw new IllegalArgumentException("Неподдерживаемый канал связи " + channel);
}
}
вариант с if
public List<String> getTypes2(Channel channel) {
if (INTERNET == channel) {
return Arrays.asList("SMS", "MAC");
}
if (HOME_PHONE == channel || DEVICE_PHONE == channel) {
return Arrays.asList("CHECK_LIST");
}
throw new IllegalArgumentException("Неподдерживаемый канал связи " + channel);
}
Итого для меня: switch/case/default VS if.
Если спросить, кому какой нравится больше код, то большинство отдаст предпочтение 1ому варианту, в то время как по мне, он — многословный. Речь о рефакторинге кода здесь не идет, все мы знаем, что можно было бы использовать константу типа EnumMap или IdentityHashMap для поиска списка по ключу channel или вообще убрать нужные данные в сам Channel, хотя это решение дискуссионное. Но вернемся.
2. Отступы
Возможно в академических примерах использование оператора swicth — это единственная часть кода, но тот код, с которым приходится сталкиваться, поддерживать — это более сложный, обросший проверками, хаками, где-то просто предметной сложностью код. И лично меня, каждый отступ в таком месте напрягает. Обратимся к 'живому' примеру (убрал лишнее, но суть осталась).
public static List<String> getReference1(Request request, DataSource ds) {
switch (request.getType()) {
case "enum_ref":
return EnumRefLoader.getReference(ds);
case "client_ref":
case "any_client_ref":
switch (request.getName()) {
case "client_types":
return ClientRefLoader.getClientTypes(ds);
case "mailboxes":
return MailboxesRefLoader.getMailboxes(ds);
default:
return ClientRefLoader.getClientReference(request.getName(), ds);
}
case "simple_ref":
return ReferenceLoader.getReference(request, ds);
}
throw new IllegalStateException("Неподдерживаемый тип справочника: " + request.getType());
}
вариант с if
public static List<String> getReference2(Request request, DataSource ds) {
if ("enum_ref".equals(request.getType())) {
return EnumRefLoader.getReference(ds);
}
if ("simple_ref".equals(request.getType())) {
return ReferenceLoader.getReference(request, ds);
}
boolean selectByName = "client_ref".equals(request.getType()) || "any_client_ref".equals(request.getType());
if (!selectByName) {
throw new IllegalStateException("Неподдерживаемый тип справочника: " + request.getType());
}
if ("client_types".equals(request.getName())) {
return ClientRefLoader.getClientTypes(ds);
}
if ("mailboxes".equals(request.getName())) {
return MailboxesRefLoader.getMailboxes(ds);
}
return ClientRefLoader.getClientReference(request.getName(), ds);
}
Итого для меня: 5 отступов VS 2.
Но опять, кому какой нравится вариант? Большинство отдаст предпочтение getReference1.
Отдельно стоит отметить, что количество отступов еще зависит от выбранного стиля форматирования кода.
3. Проверка на null
Если используется оператор switch со строками или енумами параметр выбора необходимо проверять на null. Вернемся к getTypes примерам.
// switch: проверка на null нужна
public List<String> getTypes1(Channel channel) {
// Проверка на null
if (channel == null) {
throw new IllegalArgumentException("Канал связи должен быть задан");
}
switch (channel) {
case INTERNET:
return Arrays.asList("SMS", "MAC");
case HOME_PHONE:
case DEVICE_PHONE:
return Arrays.asList("CHECK_LIST");
default:
throw new IllegalArgumentException("Неподдерживаемый канал связи " + channel);
}
}
// if: можно обойтись без проверки на null
public List<String> getTypes2(Channel channel) {
if (INTERNET == channel) {
return Arrays.asList("SMS", "MAC");
}
if (HOME_PHONE == channel || DEVICE_PHONE == channel) {
return Arrays.asList("CHECK_LIST");
}
throw new IllegalArgumentException("Неподдерживаемый канал связи " + channel);
}
Итого для меня: лишний код.
Даже если Вы абсолютно уверенны сейчас в том, что null 'не придет', это абсолютно не значит, что так будет всегда. Я проанализировал корпоративный багтрэк и нашел этому утверждению подтверждение. Справедливости ради стоит отметить, что структура кода выраженная через if не лишена этой проблемы, зачастую константы для сравнения используются справа, а не слева, например, name.equals(«John»), вместо «John».equals(name). Но в рамках данной статьи, по этому пункту, хотел сказать, что при прочих равных, подход со switch раздувается проверкой на null, при if же проверка не нужна. Добавлю еще, что статические анализаторы кода легко справляются с возможными null-багами.
4. Разношерстность
Очень часто, при длительном сопровождении кода, кодовая база раздувается и можно легко встретить код, похожий на следующий:
public static void doSomeWork(Channel channel, String cond) {
Logger log = getLogger();
//...
switch (channel) {
//...
case INTERNET:
// Со временем появляется такая проверка
if ("fix-price".equals(cond)) {
// ...
log.info("Your tariff");
return;
}
// Еще под выбор?
// ...
break;
//...
}
//...
}
Итого для меня: разный стиль.
Раньше был 'чистенький' switch, а теперь switch + if. Происходит, как я называю, смешение стилей, часть кода 'выбора' выражена через switch, часть через if. Разумеется никто не запрещает использовать if и switch вместе, если это не касается операции выбора/под выбора, как в приведенном примере.
5. Чей break?
При использовании оператора switch, в case блоках может появиться цикл или на оборот, в цикле — switch, со своими прерываниями процесса обработки. Вопрос, чей break, господа?
public static List<String> whoseBreak(List<String> states) {
List<String> results = new ArrayList<>();
for (String state : states) {
Result result = process(state);
switch (result.getCode()) {
case "OK":
if (result.hasId()) {
results.add(result.getId());
// Надуманный случай, но break чей-то?
break;
}
if (result.getInnerMessage() != null) {
results.add(result.getInnerMessage());
// Вот это поворот
continue;
}
// ...
break;
case "NOTHING":
results.add("SKIP");
break;
case "ERROR":
results.add(result.getErroMessage());
break;
default:
throw new IllegalArgumentException("Неверный код: " + result.getCode());
}
}
return results;
}
Итого для меня: читаемость кода понижается.
Если честно, встречались и куда более запутанные примеры кода.
6. Неуместность
В java 7 появилась возможность использовать оператор switch со строками. Когда наша компания перешла на java 7 — это был настоящий Switch-Бум. Может по этому, а может и по другой причине, но во многих проектах встречаются похожие заготовки:
public String resolveType(String type) {
switch (type) {
case "Java 7 же?":
return "Ага";
default:
throw new IllegalArgumentException("Люблю switch, жаль, что нет такого варианта с case " + type);
}
}
Итого для меня: появляются неуместные конструкции.
7. Гламурный switch под аккомпанемент хардкода
Немного юмора не помешает.
public class Hit {
public static enum Variant {
ZERO, ONE, TWO, THREE
}
public static void switchBanter(Variant variant) {
int shift = 0;
ZERO: ONE: while (variant != null) {
shift++;
switch (variant) {
default: {
THREE: {
System.out.println("default");
break THREE;
}
break;
}
case ONE: {
TWO: {
THREE: for (int index = shift; index <= 4; index++) {
System.out.println("one");
switch (index) {
case 1: continue ONE;
case 2: break TWO;
case 3: continue THREE;
case 4: break ZERO;
}
}
}
continue ONE;
}
case TWO: {
TWO: {
System.out.println("two");
if (variant == THREE) {
continue;
}
break TWO;
}
break ZERO;
}
}
variant = null;
}
}
public static void main(String[] args) {
switchBanter(ONE);
}
}
Без комментариев.
Заключение
Я не призываю Вас отказываться от оператора switch, местами он действительно хорош собой и лапша из if/if-else/else та еще каша. Но черезмерное его использование где ни попадя, может вызывать недовольство у других разработчиков. И я один из них.
Отдельно хотелось отметить, что c точки зрения понимания кода, у меня нет никаких проблем с switch/case — смысл написанного ясен, но вот с точки зрения восприятия эстетической красоты — есть.
И напоследок. Используйте то, что Вам приходится по душе, опуская за скобки навязанные мнения, главное, чтобы Ваш код был простым, рабочим, красивым и надежным. Всего хорошего.
Автор: reforms
