On Thursday, February 9, 2012 1:39:10 AM UTC+1, dparish wrote:
>
> Thomas,
>
> I'm working on restructuring AppActivityMapper so that I inject in the
> Activities. My reasoning for the static injector was it kept me from
> having gigantic constructor arguments. If AppActivityMapper has 30
> activities, that's alot of constructor arguments.
>
I also prefer constructor injection, but in the case of ActivityMapper-s,
which have a lot of dependencies, I make an exception and simply use field
injection:
class AppActivityMapper implements ActivityMapper {
@Inject Provider<FooActivity> fooActivityProvider;
@Inject Provider<BarActivity> barActivityProvider;
…
> MyApp.getInjector().getActivityFoo() seemed like a very clean way to get
> around that. I get that it breaks injection though.
>
What's the difference between declaring 30 dependencies in
AppActivityMapper and declaring 30 accessor methods in the Ginjector?
In our case, we actually make an heavy use of assited-inject, so we declare
factory interfaces within the AppActivityMapper and simply inject that
factory (I generally prefer declaring an inner Factory interface in the
type that's being constructed, but we make an exception for activities and
use a single –or only a few– factory that can provide many activity types,
and declare it within the ActivityMapper).
Of course, YMMV.
I could pass in the injector but I suspect that's bad form as well ;)
>
Would still be better than accessing a static field (you could possibly
mock the Ginjector if you wanted to unit-test your ActivityMapper)
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/AsT7yuM3XuoJ.
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-web-toolkit?hl=en.
