2V0-72.22PSE · Question #32
Why is field-based dependency injection not recommended?
The correct answer is A. It hides the dependencies D. It disallows final/immutable field declaration. Field-based dependency injection is discouraged primarily because it hides a class's dependencies behind framework magic - you can't tell what a class needs just by looking at its constructor or public API, making it harder to understand, test, and maintain. It also prevents…
Question
Why is field-based dependency injection not recommended?
Options
- AIt hides the dependencies
- BBecause it does not use Class-based Dependency Injection
- CBecause it uses the Java Reflection API, which may adversely impact performance
- DIt disallows final/immutable field declaration
How the community answered
(26 responses)- A85% (22)
- B4% (1)
- C12% (3)
Explanation
Field-based dependency injection is discouraged primarily because it hides a class's dependencies behind framework magic - you can't tell what a class needs just by looking at its constructor or public API, making it harder to understand, test, and maintain. It also prevents fields from being declared final, since the DI container must set them via reflection after object construction, eliminating immutability guarantees that constructor injection preserves.
Why B is wrong: The comparison to "Class-based Dependency Injection" is nonsensical - constructor and setter injection also operate on classes; this isn't a meaningful distinction.
Why C is wrong: Field injection does use the Reflection API, but negligible reflection overhead on modern JVMs is not the reason it's discouraged - this is a red herring that sounds technical but isn't the real concern.
Memory tip: Think "HIDE and FINAL" - field injection hides dependencies (A) and kills final fields (D). Constructor injection does the opposite: it makes dependencies explicit and allows immutable fields.
Topics
Community Discussion
No community discussion yet for this question.