Cédric, Assuming you don't use setters, how do you test without an injector or hacked up reflection? How do you inject mocks without a bunch of boilerplate?
Constructor injection uses a language construct and is testable in many different forms (mocked, injected, null, etc.). Private field injection is using a backdoor in an API. Constructor injection also provides documentation and a contract. Additionally, the JVM makes guarantees about language constructs like constructors. It does not do this for libraries, even those with JSR interfaces like Guice. Although, Guice is solid and we all trust it, field injection does not have the same guarantees from the JVM as constructors. -- Brian Sent from my iPad > On Nov 24, 2013, at 11:24 AM, Cédric Beust ♔ <[email protected]> wrote: > > Tim, that’s a great summary of the philosophy behind Guice, and I agree with > most of what you wrote, but I’ll comment on a few tiny things: > >> On Sun, Nov 24, 2013 at 10:08 AM, Tim Boudreau <[email protected]> wrote: >> >> You don't really forfeit control over your fields unless you want to. >> First, you *can* inject into private fields if you feel like it - Guice will >> do it. I don't think that's actually a good idea > > Personally, I prefer it over constructor injection. You lose final but it > considerably reduces the amount of boiler plate. > > Contrast: > > private final FooService fooService; > private final BarService barService; > > @Inject > public MyClass(FooService fooService, BarService barService) { > this.fooService = fooService; > this.barService = barService; > ) > With: > > @Inject > private FooService fooService; > > @Inject > private BarService barService; > The question then becomes: is this trade off worth it? > > I would be totally on board with constructor injection if final guaranteed > structural immutability, but all it does is guarantee reference immutability > (“this field is only assigned once”), and in my experience, bugs occurring > because a field (or a variable) gets assigned twice are extremely rare (and > reassigning is very rare on top of that). > >> , but it's possible. For that, you do give up the ability to have those >> fields be final - which to me is unacceptable - if it can mutate, you have >> to assume it does mutate, so anything I don't actually intend to be mutable >> should not be. The final keyword is a great way to let the compiler help >> prove your program is correct and reduce the number of possible states your >> program might have. > > Again, final enforces a very weak, and not that useful, aspect of > immutability. > > If you want your program to use as many immutable structures as possible, you > have to implement it this way (e.g. ImmutableMap, etc…). > > -- > Cédric > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/google-guice. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/groups/opt_out.
