Если посмотреть на большой оператор switch то можно заметить рваную простыню в которой мало что понятно. Особенно если там много локальных переменных состояния.

А ведь можно произвести полиморфный рефакторинг.

Сначала делается инкапсулирующее разбиение переменных.

Затем разбиение кода на методы по переменным, которые инкапсулировали.

Потом разнесение кода между ~case ... break по разным функциям.

Дальше нужно спроектировать к каким объектам относятся ветки оператора переключения switch.

Далее заводятся наследники от класса выбранного объекта

Проставляются переменные состояния и методы варианты switch

Для того чтобы каждый раз не писать кучу условий if и switch заводятся методы для каждой обработки данных в программе

Короче для простоты кода и ухода от "спагетти кода" на входе основных данных заводится объект под каждый случай switch

Может получится довольно интересная структура наследования

Короче после связывания объектов на входе получиться что грамоздкий switch заменяется на вызов одного метода

Это и есть паттерн дискретезирующего рефакторинга.

Не смотря на удобство есть исключение - парсеры

В парсинге нет нужды заводить объекты потому что switch для задачи один, потому принято писать большой метод. Он понятнее

Понятность и удобство спорные стороны в двух смыслах

ЗАМЕЧАНИЕ: Если у вас много переменных состояния в switch подумайте про варианты инкапсуляции ИЛИ используйте record и задумайтесь про паттерн визитер