Кто-нибудь не согласен с утверждением: «использование switch - плохой стиль ООП»?

Question

Я видел, как в нескольких потоках / комментариях к stackoverflow написано, что использование switch - просто плохой стиль ООП. Лично я с этим не согласен.

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

Наконец, переключатели лаконичны и понятны:

boolean investable;
switch (customer.getCategory()) {
    case SUB_PRIME:
    case MID_PRIME:
        investible = customer.getSavingsAccount().getBalance() > 1e6; break;
    case PRIME:
        investible = customer.isCeo(); break;
}

Я не защищаю каждое использование switch, и я не говорю, что всегда есть путь. Но такие утверждения, как «Переключатель - это запах кода», на мой взгляд, просто неверны. Кто-нибудь еще согласен?

Answer 1

"Кроме того, что, если будут постоянно появляться новые продукты, каждый с различными решениями для инвестиций, и я не хочу обновлять свой основной класс клиентов каждый раз, когда это происходит?"

Это приходит на ум:

interface Investable
{
    boolean isIvestible(Customer c);
}

class FooInvestible 
    implements Investible
{
    public boolean isInvestible(final Customer c)
    {
        // whatever logic, be it switch or other things
    }
}

«Проблема» с оригинальным использованием swtich и добавлением новых типов решений заключается в том, что вы, скорее всего, столкнетесь с огромным количеством кода для крыс, который невозможно поддерживать нормальным способом. Разделение решений на классы вынуждает разделять решения. Тогда, даже если вы используете switch, код, скорее всего, останется более разумным и поддерживаемым.

Answer 2

Операторы case почти всегда можно заменить полиморфизмом

А также

boolean investable = customer.isInvestable();

Поскольку вызов isInvestable является полиморфным, фактический алгоритм, используемый для выполнения вызова, определяется типом клиента.

Я думаю, что вы оба не правы . Что делать, если это просто логика «инвестируемости» для клиента, желающего получить бизнес-кредит. Возможно, решение неуязвимости клиента для другого продукта действительно совсем иное, и, возможно, не в зависимости от «категории», а от того, где они живут, состоят ли они в браке, в какой сфере труда они работают?

Кроме того, что, если постоянно появляются новые продукты, каждый с различными решениями для инвестиций, и я не хочу обновлять свой основной класс Customer каждый раз, когда это происходит?

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