Переключатели являются запахом кода при использовании в чистом коде OO. Это не значит, что они ошибочны по определению, просто нужно подумать об их использовании. Будьте особенно осторожны.
Мое определение переключателя здесь также включает операторы if-then-else, которые можно легко переписать как операторы switch.
Переключатели могут быть признаком того, что вы не определяете поведение, близкое к данным, с которыми он работает, и не используете, например, полиморфизм подтипа.
При использовании языка OO вы не обязаны программировать в режиме OO. Поэтому, если вы решите использовать более функциональный или объектный стиль программирования (например, использование DTO, которые содержат только данные, но не ведут себя, в отличие от более богатых моделей предметной области), в использовании переключателей нет ничего плохого.
Наконец, при написании ОО-программ переключатели оказываются очень полезными на «краю» вашей ОО-модели, когда что-то входит в вашу ОО-модель из внешнего мира без ОО, и вам нужно преобразовать эту внешнюю сущность в понятие ОО , Лучше всего сделать это как можно раньше. Например: int из базы данных можно преобразовать в объект с помощью переключателя.
int dbValue = ...;
switch (dbValue)
{
case 0: return new DogBehaviour();
case 1: return new CatBehaviour();
...
default: throw new IllegalArgumentException("cannot convert into behaviour:" + dbValue);
}
РЕДАКТИРОВАТЬ после прочтения некоторых ответов.
Customer.isInvestable: отлично, полиморфизм. Но теперь вы привязываете эту логику к клиенту, и вам нужен подкласс для каждого типа клиентов, просто чтобы реализовать различное поведение. В прошлый раз, когда я проверял, это не то, как наследование должно использоваться. Вы бы хотели, чтобы тип клиента был свойством Customer или имел функцию, которая может определять тип клиента.
Двойная отправка: полиморфизм дважды. Но ваш класс посетителей, по сути, все еще имеет большое значение, и у него есть некоторые из тех же проблем, что описаны выше.
Кроме того, по примеру OP полиморфизм должен относиться к категории клиента, а не к Customer.
Включение значения в порядке: хорошо, но операторы switch в большинстве случаев используются для тестирования одного значения int, char, enum, ..., в отличие от if-then -также можно проверить диапазоны и более экзотические условия. Но если мы отправляем это единственное значение, и оно не находится на грани нашей ОО-модели, как объяснено выше, тогда кажется, что переключатели часто используются для диспетчеризации по типу, а не по значению. Или: если вы можете , а не заменить условную логику if-then-else переключателем, то вы, вероятно, в порядке, в противном случае, вероятно, нет. Поэтому я думаю, что переключатели в ООП - это запах кода, а утверждение
Включение типа - плохой стиль ООП,
переключение значения в порядке.
само упрощено.
И вернемся к исходной точке: switch неплохо, просто не всегда ОО. Вам не нужно использовать ОО, чтобы решить вашу проблему. Если вы используете ООП, то переключатели - это то, что вам нужно уделить дополнительное внимание.