2009/10/26 Gili Tzabari <[email protected]> > ... but in practice, how often does that actually happen? It sounds > to > me like dependency injection is mostly about testability, not code > reuse, 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). >
Just wondering, have you read http://martinfowler.com/articles/injection.html ? Dependency injection isn't just good for testing, it helps reduce coupling between components. These days I find I program to interfaces much more than to concrete classes (though I try not to go overboard with interfaces!) and DI is a great way to wire these bits together. Especially as I can then switch bindings between simple instantiations or dynamic lookup, or apply different conversation scoping without littering my code with various thread constructs. 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. Good for testers, > bad for users :) > Ironically I've found DI helps me avoid being tied to specific APIs (case in point, OSGi services) because I can isolate their use in binding modules and providers, rather than in the code itself. And so far DI + services has definitely been good for my users :) > Gili > > Richard Nichols wrote: > > If the only problem you are trying to solve is testing of singletons, > > then Guice doesn't offer you much advantage. > > > > Remember that Guice is primarily designed to make implementation of > > dependency injection simpler, and that's a design pattern which will > > affect your entire code base, if your code is not factored that way. > > Scoping (e.g. singletons) is another feature provided by Guice to help > > simplify the DI pattern, but it is only one aspect. > > > > DI isn't just about testability, but other factors such as code reuse > > as well. A singleton which is implemented as a static will be less > > reusable than an object bound in SINGLETON scope with Guice, since you > > can decide whether it should be a singleton, bound in request or > > session scope (for a web app), thread scope etc. A singleton in one > > app, might be suitable in a different scope usage in a different app. > > > > On Oct 26, 6:14 am, Gili <[email protected]> wrote: > >> Hi, > >> > >> It is my understanding that one of the main reasons for using Guice is > >> that it is difficult to ensure that static state (such as singletons) > >> get reset across JUnit tests. Isn't that what ClassLoaders are for? > >> > >> What's the advantage of using Guice versus a JUnit runner that simply > >> uses a different ClassLoader per test to ensure that static state gets > >> reset? > >> > >> Thanks, > >> Gili > > > > > > > > > > -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
