On Tue, May 10, 2011 at 9:47 AM, David Hoffer <[email protected]> wrote: > 1. Hum, perhaps I'm doing more work than I need to...perhaps just out > of habit of previously using manual factories...but I think I got this > from the Guice online docs. Here is what I do: > > Class A takes 4 parameters where all are interfaces of course. I add > @Inject annotation to the constructor and optionally scope annotation > to the class. I then create a module for this class that extends from > AbstractModule that implements configure. In this method I create and > maintain 4 bind() method calls that map the interface to the actual > class. I assume the order of these bind statements much match the > order in the constructor. Repeat for every IoC class in the > application. ekk, you certainly do not need to do that. For most classes you do not need to have anything in an AbstractModule. I use it mostly to add in old non-guiced classes and for these I normally use a @Provides annotation on a method in the module.
Peter > > I guess I just don't get your comment 'bind()ings are about *what* to > inject, not *where* to inject them.' It seems you need some way to > specify the *where* too. > > -Dave > > > > On Tue, May 10, 2011 at 11:17 AM, Thomas Broyer <[email protected]> wrote: >> >> >> On Tuesday, May 10, 2011 9:25:08 AM UTC+2, dhoffer wrote: >>> >>> Thanks for the reply... >>> >>> Regarding 1 at a minimum I need the code/refactoring support one would >>> get if using manual factories. E.g. If I add a constructor parameter >>> or change parameter order I need it to keep the module/factory in >>> sync. In IDEA reordering would change it everywhere, adding something >>> new would have a default value. So it should at least add another >>> bind() to the module where I have to fill out the types (and fail to >>> compile until I do). As it is now I have to manually keep both in >>> sync. My IDE has become Notepad. >> >> bind()ings are about *what* to inject, not *where* to inject them. Adding a >> parameter to an @Inject-ed constructor doesn't mean you need a bind()ing, >> unless your new parameter's *type* needs a bind()ing; but that's when you >> create the *type* that you need to add the bind()ing, not when you use it. >> Guice is all about not having to maintain "factories": if you need a new >> dependency in a class, just add an argument to your @Inject-ed constructor, >> or an @Inject-ed field or method; you don't have to go through hoops of >> maintaining some factory. >> Maybe you'd like your IDE to warn you if your app is missing a dependency >> binding, but that's hard to do because Guice is about modularity: you >> wouldn't want your IDE to warn you of a missing dependency if you're >> developping a library where the dependency is meant to be provided by the >> "context/environment" the library is used in (e.g. some library depends on a >> JMS queue or JDBC connection, and the app that uses the library has to >> provide the binding) >> >>> >>> As a bonus the IDE should create the module as else the module really >>> doesn't save any coding. But I understand this is not a Guice problem >>> it's a desired IDE feature. >>> >>> 1b. Another example, with Guice I can't even ask the IDE to find uses >>> of a constructor so I can find where it's used/created because that >>> usage is hidden behind the magic of annotations. Again my IDE has >>> become Notepad. >> >> Because the class should only be instantiated by Guice, and you should let >> Guice inject it (i.e. not pass it around yourself), you can simply search >> for uses of the class itself. >>> >>> 2. In the module for a class (which is its factory) >> >> No, the module only provides "configuration", the "factory" is the Injector >> you build with it (and other modules). >> >>> >>> I can have >>> completely wrong bind statements and the compiler doesn't care. >> >> How's it different from having "completely wrong" code in a factory method? >> >>> >>> It's >>> not until runtime that errors are seen. Unit tests generally use >>> mocks (that's why its IoC) so that won't catch the error either. I >>> can add another test...really an integration test that causes Guice to >>> create a live instance...that should catch any problems...but I'm >>> concerned about that working in the general case because sometimes >>> that will require lots of application code to fire up...not what is >>> desired in a unit test. >>> >>> I guess my point here is that with manual factories those didn't need >>> to be unit tested because with the compiler's help those are >>> binary...you either have one or you don't...nothing really to test. >>> With Guice lots can go wrong in the factory (Module). And because I >>> have no IDE help to maintain the module...lots does go wrong. >> >> Can you give a concrete example? (code!) >> >>> >>> 3. I'll review and see if I can make improvements in how I manage >>> modules. To start I just had one package for these for the app...that >>> was no good so now I name the module the same as the class with Module >>> suffix and put in the same package as the class, that way I know where >>> it is. I have one master class where I new up all the modules and add >>> to Guice.createInjector(). Not sure yet how this will work. >>> >>> Thanks again for you help... >> >> -- >> 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. >> > > -- > 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. > > -- 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.
