5 ms·
Reflection allows you to put the interfaces to Account and Customer into a shared module and the business logic implementations into their own mutually independ
by gorky1 6y ago
Reflection allows you to put the interfaces to Account and Customer into a shared module and the business logic implementations into their own mutually independent modules, thus removing the cyclic compile time dependency.
You "wire up" the implementations at runtime, using reflection.
- Ma8ee 6y agoI still don't get it. I put the interface into a shared module and the implementations in independent modules without reflection. Why exactly would we need reflection to do that?
- Smaug123 6y agoIf I may, that sounds horrifying. Please, for the sake of my sanity and the IDE, always do things at compile time rather than runtime if you can!
- ldlework 6y agoIf the code is implementing against interfaces, why would late binding mess up your IDE experience at all?
- gorky1 6y agoI've seen people learning about dependency inversion from a book called "Clean Architecture", then proceeding to apply it to every bit of code they write, to make it "clean". It makes code difficult to trace by reading alone. Indirection may be cheap, but it adds up.
- Smaug123 6y agoMy heart sinks whenever I need to spend ten minutes trying to work out which of the three different implementors is actually going to be called on a particular code path. For about a week of December, my work was solely spelunking to track down which implementations of an interface in C# were dead code and so on.
- bmm6o 6y agoRight. Often there are 2 types of interfaces in a project. The first are "natural" interfaces, that you have put some design into and are meant to be reusable. Things like Streams or Collections. When you write a function that uses one of these, you really are expecting to be able to use any implementation. If you want to go to the implementation of Stream.Read, obviously the IDE isn't going to be able to do it, it's abstract and there are any number of implementations. 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.
- ahepp 6y agoIs there any solution to this?
- bmm6o 6y agoIt seems like an IDE could know if there is a single implementation and could go to it, especially if the interface is not visible outside the project ("internal" in C#). In practice, the interface is in the same file as the primary implementation, so it's not as bad as it seems. More of an annoyance.
- jonathanlydall 6y agoJetbrain’s Rider as well as their ReSharper for Visual Studio have a navigate to implementation feature which I use the shortcut key for all the time. 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.
- gorky1 6y agoIt'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.
- samus 6y agoThis is perfectly possible without reflection. The interfaces already make it possible.