3 ms·
It's called the "dependency inversion principle". People don't like to call it "reflection", and heap various layers like XML or dependency injection annotions
by gorky1 6y ago
It's called the "dependency inversion principle". People don't like to call it "reflection", and heap various layers like XML or dependency injection annotions on it, but technically, it comes down to reflection at runtime, as far as I've seen.
It certainly has its cost in additional complexity through indirection, but it's better than creating cyclic dependencies or giant balls of mud.
https://en.m.wikipedia.org/wiki/Dependency_inversion_principle https://en.m.wikipedia.org/wiki/Dependency_inversion_princip...
- Ma8ee 6y agoNo, you don’t need reflection or annotations to use dependency inversion. Why do you think so?
- gorky1 6y agoThe question was "what has reflection got to do with it". I've used reflection for dependency inversion, so I think that's what it's got to do with it. If you can do dependency inversion without reflection, more power to you :-) We can't do classpath scanning in the project I'm working on because of the size of the classpath, and compile time configuration using direct imports would introduce cycles, so reflection it is for us, in one form or another.
- Too 6y agovoid createAccount(ICustomer c) { ... } // No dependency to concrete Customer class Customer implements ICustomer { ... } // Customer Class can be created after Account above createAccount(new Customer()) // Use of both, with dependency injection Scanning for classes dynamically using reflection has nothing to do with above. And you certainly don't need any xml or framework to do it either.