Случай переключения Java - по умолчанию против явного перечисления - PullRequest
5 голосов
/ 11 января 2011

Я использую Java 6.

Предположим, у меня есть перечисление с 6 значениями, упорядоченные от A до F. Около 4 значений обрабатывались одинаково. Я мог бы написать это так.

switch (whichType) {
    case A:
    case B:
    case C:
    case D:
        return task();
    case E:
        return someothertask();
    case F:
        return anothersomeothertask();
}

Или вот так.

switch (whichType) {
    case E:
        return someothertask();
    case F:
        return anothersomeothertask();
    default:
        return task();
}

Нулевые значения никогда не достигнут этого переключателя.

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

Есть ли другие плюсы / минусы каждого подхода?

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

Ответы [ 5 ]

7 голосов
/ 11 января 2011

Оба хороши, если это перечисление абсолютно, положительно зафиксировано на шести значениях навсегда. В противном случае подумайте, каким может быть возможное седьмое значение для перечисления. Если E и F являются единственными двумя возможными выбросами по отношению к этой switch логике, и любое другое значение попадет в тот же сегмент, что и от A до D, продолжайте и используйте default. В противном случае вам будет безопаснее иметь case на значение.

3 голосов
/ 11 января 2011

Предположим, кто-то добавляет значение в перечисление?

В некотором коде, который у меня есть, есть такая конструкция:

switch(mediaType) {
    case typeA:
    case typeB:
    case typeC:
        DoGeneric();
        break;
    case TypeD:
        DoSpecial();
        break;
}

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

2 голосов
/ 05 декабря 2013

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

switch (whichType) {
    case A:
    case B:
    case C:
    case D:
        return task();
    case E:
        return someothertask();
    case F:
        return anothersomeothertask();
    default:
        throw new IllegalArgumentException("Encountered unknown type: " + whichType.name());
}
2 голосов
/ 11 января 2011

Ну, что касается читабельности, я бы сказал, что второе не может быть более ясным. Например, ваш общий случай случается ПОСЛЕ ваших особых случаев.

Однако реальная проблема, которую я вижу здесь, состоит в том, что два фрагмента кода на самом деле не эквивалентны. В первом случае у вас есть шесть явных случаев. Во втором у вас есть два явных случая и один случай по умолчанию. Это означает, что, если в вашем коде есть какая-то ошибка, когда вы получаете случай, который вы не ожидали, случай по умолчанию все равно будет выполняться во втором (и task() все равно будет выполняться). В результате это в корне отличается от вашего первого кода.

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

0 голосов
/ 11 января 2011

Если вы пишете какой-то бизнес-сценарий и ожидаете, что код будет жить и будет поддерживаться (другим человеком) в течение многих лет, выберите вариант 1. В варианте 2 нет ничего плохого, он короткий Ясно, но когда речь идет о ремонтопригодности, я думаю, что вариант 1 выигрывает, особенно если случаи связаны с некоторой бизнес-логикой. Обслуживающему инженеру будет намного легче его прочитать.

...