D
по ссылке несколько решений
Size: a a a
2021 November 24
S
используется в смысле под капотом или ручками с бинами возишься?
2021 November 25
DC
Под капотом, в бизнес-коде стоит всеми средствами его избегать
S
а если это дебаг\тесты
S
хотя сложно кейсы придумать, опыта нет ж
ST
Почему? В случае если код очевидный и не усложняет ничего.
DC
Дебаг - это, как правило, не написание кода
Тесты - с вероятностью в 95% тесты с рефлексией это херня какая-то, которую будет очень сложно поддерживать, но очень иногда может быть
Тесты - с вероятностью в 95% тесты с рефлексией это херня какая-то, которую будет очень сложно поддерживать, но очень иногда может быть
DC
>код очевидный и не усложняет ничего
>рефлексия
выбери одно из двух
>рефлексия
выбери одно из двух
S
ладно, положил на полочку знаний, будет чем похвастаться за кружкой пива
ST
Списком прочитать поля модели или добавить кастомный валидатор, например. В обоих случаях код как по мне обычно очевидный
DC
Зачем тебе читать поля модели в бизнес-логике?
DC
У тебя известны модели, с которыми ты в коде работаешь, у тебя язык со статической типизацией, тебе не надо "читать поля", тебе нужна конкретная функциональность с конкретными моделями и конкретными их полями
A
например приходит запрос с названием поля модели, и тебе нужно проверить - существует ли такое поле
DC
1) И для чего это с точки зрения бизнес-логики?
2) Тебе список полей и их имён compile-time известен, напиши свитчкейс по строкам
2) Тебе список полей и их имён compile-time известен, напиши свитчкейс по строкам
A
если полей 100?
A
просто getClass().getFields(), что этот вызов сделает плохого?
DC
То тебе 85 полей назад пора рефакторить приложение
DC
И ты не ответил на первый вопрос
DC
Искусственных кейсов можно хоть обпридумываться, но зачем
A
я образно, допустим 20, 30 важных данных, всеравно свитч кейс так себе