On Tue, May 10, 2011 at 3:25 PM, David Hoffer <[email protected]> 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. Changing constructor parameter order shouldn't affect Guice at all. Guice uses the one constructor with @Inject or a default constructor (constructor without any argument). If you remove the default constructor (without @Inject constructor), it will be break Guice without any compile time warning. Let's say you have a class with an @Inject constructor already. When you add a parameter to that constructor, you got to make sure Guice can wire the parameter. If not, Guice's injection will fail in runtime again (with proper error message). So it's true some checking are done in runtime in compare to the manual way. When you use a Dependency Injection framework, for the objects you decide to let the DI framework to manage, you don't call the constructors directly in your code. so you are not expected to search/refactor the constructor usage. I think the above compile time checking is not a meaningful benefit in compare to the benefit of dependency injection. Take an example from Guice's getting start page: http://code.google.com/p/google-guice/wiki/GettingStarted Assume at the beginning RealBillingService has a one CreditCardProcessor paramater only, and then you decide to add one more parameter namely TransactionLog. In your "manual factory", where do the TransactionLog come from? creating the TransactionLog could be complex, the tranactionLog could have a lot of fields and has a lot of dependencies and may require a correct construction sequence. Without a IoC framework, you need to code them all in your factory. With a DI framework, you focus on your application logic rather than infrastructure code. You have the flexibility to change the implementation. > 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. > I don't expect any IDE could be so intelligent to help/warn me in the above cases. In a project that use Guice, there could be classes that are not injected by Guice, and I don't want the IDE to warn me or do anything when I'm changing the constructor of those classes. And there could be multiple Guice module classes and there is no way for an IDE to know which one you want to put the binding configuration at. > > 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. > if you name all modules as *Module, you could do a Find Usage of a particular class/interface in all "*Module.java" files so it roughly can locate the relevant configuration quickly. regards, mingfai -- 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.
