Пять строк кода. Роберт Мартин рекомендует 35

Мне кажется, что многие рекомендации спорные.
В частности замена свича на объект оправдана не всегда, а если в коде есть несколько логически связанных действий с этим свичом.
Многие такие преобразования на самом деле имеют свою цену в терминах сложности и поэтому замена не всегда оправданна.

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

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

В каждой кодовой базе есть ошибки и слабые места, которые нужно найти и исправить. Правильный рефакторинг сделает ваш код элегантным, удобным для чтения и простым в обслуживании. Познакомьтесь с уникальным подходом, позволяющим реализовать любой метод в пяти строках кода. И не забывайте про тайну, хорошо известную большинству senior-разработчиков: иногда проще ухудшить код и вернуться к его исправлению позже. «Пять строк кода» — это свежий взгляд на рефакторинг для разработчиков любого уровня. Вы узнаете, когда проводить рефакторинг, как использовать паттерны, а также научитесь определять признаки, которые говорят о том, что код необходимо удалить.

Я могу быть неправ, но мое мнение об этом всем такое:

Да, логику фильтрации/валидации нужно отделять от процессов обработки

Да, енумы лучше констант инт/стринг, потому что не позволит просто взять и присвоить недопустимое значение (для языков с типизацией: можно, но придется извратиться, для языков без типизации - не знаю, не уверен)

Как всегда, красивая теория над простыми примерами. В жизни все немного (много) сложнее. Код с отложенной реализацей сложнее отлаживать, хоть и проще читать, если не нужно вникать в саму реализацию. Но это, опять же, на простых примерах. На энтерпрайзе у меня пока не было такой практики, при которой условия со свичами были бы переписаны на объектную модель и при этом это и легко читается, и легко дополняется, и легко отлаживается. Это как с тем треугольником консистентности прям.