On Mon, Oct 26, 2009 at 14:55, Gili Tzabari <[email protected]> wrote:
> > > ... 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). > > 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 :) > You are very obviously using Guice utterly wrong! :-) Guice is only one of a dozen tools for doing DI (or "IoC" or "don't call us, we'll call you"-style), and was actually quite late to the game. But Guice and the concepts it embodies (yes, use of annotations instead of hellish XML) is a very intelligent way of doing DI, hence its huge following. Actually, it is rather typical to NOT use a specific DI-tool when testing, but instead doing the "wiring" of code yourself, typically with mock or dumyy objects etc. So stating that "Guice is for testing" is actually quite strange, bordering on complete display of total misunderstanding of the concept. Happy hacking, Endre. > 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 > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
