Reflection API · interview question
Why is letting reflective calls spread through core business logic an architectural risk?
Multiple choiceMediumchapter-16-curatedpremiumreflection-apibreaking-encapsulation
Answer and explanation
Correct answer
A. The code becomes fragile, string-coupled, and harder to refactor safely
Why
When business code depends on method names as strings and dynamic invocation everywhere, refactors become riskier and failures move from compile time to runtime. That makes the core flow harder to reason about and maintain.
Test yourself on Reflection API
A free test with instant, explained results. No account needed.
More Reflection API questions
- Given using Class.forName("com.example.MyClass") in Java, what outcome should you expect?
- Which method would you use to check if a class is an interface using Reflection?
- In what scenario would you prefer reflection for method invocation over direct method calls?
- Which of the following is NOT a drawback of using Java Reflection?
- If you use Method.invoke() to call a private method, what must you do first?
- How does Java's reflection API impact type safety?