You "wire up" the implementations at runtime, using reflection.
You get the other kind of interface when you want to loosely-couple your code, and so you define interfaces for many classes. Often, there is only a single class that implements the interface in your project, though there may be mock implementations in your test code. Even though there is a single "real" implementation, the IDE can't/won't jump to that implementation in the same way it won't in the first case. This is frustrating though, because it would have worked if you hadn't extracted the interface for improved testability.
The fact our solution has an interface for just about everything for testing reasons doesn’t slow me down even in the slightest when I’m looking through the code.
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_princip...
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.
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.