Hi Alexey, Others may have different advice here. This is just my two cents.
I've found that if a class has a large number of dependencies, that class usually violates the single responsibility principle. A good indicator of this is that when you write tests for such a class, the actual subset of dependencies needed to pass the test is contextual and varies from test to test. (In other words, the class has low cohesion.) Generally I try to break those classes down into smaller, more cohesive, composable units. Sometimes though a perfectly good class does have an annoyingly large dependency list. There I still prefer constructor injection, because I feel strongly that hard dependencies should be absolutely required in order to instantiate the object. Anything that's nullable in a constructor really either belongs in another class, or should be provided via a setter method (which you can mark @Inject(optional=true) for Guice). --Logan On Sat, Aug 29, 2009 at 3:49 PM, Alexey Kuznetsov <[email protected]> wrote: > > Hello, All! > > A have quite a large hierarchy of classes. Root classes have smal > count of injections, but children classes have more and more. And it > is become painful (a lot of boilerplate) to promote all this > injections through constructor injections, when you have large > hierarchy of classes. > > Currently I have a solution - do not use constructor injections, > instead use field injections. > But this aproach makes impossible to use my classes without Guice and > I cant use final modifier (which I like very mach and I can use it > with constructor injections). > > Any sugestions? > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
