Отражение Java и боль в Рефакторинге
Если кому-то все еще нужно решение, поместите в контроллер REST метод, подобный следующему:
@RestController
public class myRestController{
@GetMapping("/login")
public String redirectTo(){
return "yourRedirectLink";
}
}
Это решение очень хорошо для работы с пружиной и реакции, упакованной в банку
7 ответов
Отражение Java вызывает многие из тех же проблем, что и в языках с динамической типизацией, таких как Python и Ruby. Фактически, один из способов думать о динамически типизированных языках - это то, что все вызывается с использованием отражения, а языки просто предоставляют хороший чистый синтаксис для отражения.
И да, с динамически типизированными языками (или интенсивным использованием отражения), рефакторинг - это сложно. Вы не получите хороших возможностей рефакторинга Eclipse. Вместо этого grep становится вашим другом.
По моему опыту, лучшее, что вы можете сделать, - это создать себе хорошую страховочную сеть из модульных тестов. Таким образом, если вы сломаете какой-то динамический код во время рефакторинга, вы, по крайней мере, быстро поймаете его при запуске тестов.
Если вы выполняете много статически типизированного кода, у вас большие проблемы, если вы этого не сделаете. t иметь хорошую базу модульных тестов. Если вы пишете много динамически типизированного кода (включая код с большим количеством отражений), у вас нет никакой надежды на успех без хорошей базы модульных тестов.
Современные IDE имеют функцию, заключающуюся в том, что при переименовании класса они будут искать полное имя, например, в ваших файлах xml, чтобы попробовать и переименуйте любые ссылки, которые могут быть в них. Не думайте, что это решает проблему - очень часто вы не ссылаетесь на имена классов.
Кроме того, именно поэтому необходимо проявлять особую осторожность и внимание, прежде чем использовать его в своем собственном коде.
Но эта проблема с отражением заключается в том, почему использование аннотаций становится все более популярным. Проблема уменьшается при использовании аннотаций.
Но позвольте мне сказать, как правильно указано в предыдущем посте, если у вас нет хорошей подстраховки модульных тестов, любого вида рефакторинга, независимо от того, используете ли вы много рефлексии или нет, опасно.
Рефакторинг можно улучшить, добавив в язык больше «литералов». Например, imho .class literal - отличный способ обеспечить безопасность определенных моделей во время компиляции. Однако здесь важно сказать, что иногда я хочу потерять безопасность времени компиляции . Строки - это самый простой, но мощный способ выразить слабосвязанный контракт между двумя уровнями, поскольку вы можете манипулировать ими или сопоставлять их с регулярным выражением и т. Д.
Настоящая проблема отражения - это подробное использование API. Это основная цена гибкости.
PS
Проектная монета может ввести где-нибудь в будущем некоторую новую языковую конструкцию для улучшения этой области.
и т. д.Настоящая проблема рефлексии - это подробное использование API. Это основная цена гибкости.
PS
Проектная монета может ввести где-нибудь в будущем некоторую новую языковую конструкцию для улучшения этой области.
и т. д.Настоящая проблема рефлексии - это подробное использование API. Это основная цена гибкости.
PS
Проектная монета может ввести где-нибудь в будущем некоторую новую языковую конструкцию для улучшения этой области.
Возможно, вас заинтересует IntelliJ IDEA, которая также будет искать отредактированные имена классов в комментариях и строковых константах.
Что ж, это еще одна возможность для производителей IDE продавать дорогие премиальные версии, которые распознают и реорганизуют имена классов, используемые в определенных файлах конфигурации.
В качестве альтернативы, такие повторяющиеся случаи могут быть обработаны с помощью теста пакет, который выполняет проверку работоспособности таких файлов, то есть проверяет, существуют ли все упомянутые классы и методы. Они характерны для одного формата файла, но часто относительно легко записываются и затем могут использоваться для проверки всех файлов этого формата.
Но общего решения для прямого, "ручного" использования API отражения не существует - поэтому обычно это не рекомендуется.
Кроме того, Reflection также вызывает проблемы, если вы хотите защитить свой код с помощью обфускации. Типичные инструменты обфускации теперь требуют, чтобы вы поддерживали список всех файлов, которые вы не хотите запутывать, чтобы отражение из всех файлов конфигурации XML работало правильно.
Тем не менее, J2EE-версия Eclipse IDE вместе с подходящими плагинами для основных такие фреймворки, как Hibernate, Spring и т. д., достаточно хорошо справятся с рефакторингом. Модульные тесты сократят цикл тестирования, но проблема заключается в том, что иногда модульные тесты также зависят от некоторой конфигурации XML, вынуждающей вас использовать отражение. Таким образом, можно нарушить модульные тесты вместе с вашим кодом во время рефакторинга.
А как насчет классов, методов и полей taggin, к которым, как вы знаете, доступ осуществляется посредством отражения? IDE может предупредить вас, когда вы измените их имена.