Gili, On Mon, Oct 26, 2009 at 6:55 AM, Gili Tzabari <gili.tzab...@gmail.com>wrote:
> It sounds to > me like dependency injection is mostly about testability, not code > reuse DI is about flexibility, less boilerplate, and code reuse. Testability falls out of that. We use tests in examples because they illustrate the benefits of DI without having to involve a framework. Your solution solves one problem--resetting static state, but it doesn't help you outside of testing. Even when you're testing, it doesn't help you identify which dependencies you need to mock out. For example, I can introduce a network dep in a lower layer and make your tests run slowly or even fail. DI also greatly reduces the number of factories you need to write. and to that end ClassLoaders are actually less complex than all > the hoopla that Guice does under the hood (hint: Guice uses ASM which > uses bytecode rewriting and possibly even custom ClassLoaders). > Guice uses byte code rewriting for AOP but not DI (unless you count reading line numbers associated with methods). > Don't get me wrong, I think that Guice is a great solution for DI, > but > I wonder whether DI is the correct solution to the problem. I am > suspicious because I find it degrades API usability. When used correctly, DI can make your API smaller because you don't need to expose factory APIs. Also, I recommend making your injectable constructors package-private so you can modify them freely without breaking clients. Bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to google-guice@googlegroups.com To unsubscribe from this group, send email to google-guice+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
