FWIW, I prefer constructor injection primarily because it guarantees that
it's impossible construct the class w/o all the dependencies. Too many
tests or other pieces of code can fail for "no good reason" if they happen
to construct the class without the right dependencies. Field & method
injection subverts this, so it's easier to construct the class without
everything set.
"final" is another good reason, but far from the primary reason IMO.
sam
On Sun, Nov 24, 2013 at 1:24 PM, Cédric Beust ♔ <ced...@beust.com> 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 <niftin...@gmail.com>
> 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;
> @Injectpublic MyClass(FooService fooService, BarService barService) {
> this.fooService = fooService;
> this.barService = barService;
> )
>
> With:
>
> @Injectprivate FooService fooService;
> @Injectprivate BarService barService;
>
> The question then becomes: is this trade off worth it?
>
> I would be totally on board with constructor injection if finalguaranteed
> 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 google-guice+unsubscr...@googlegroups.com.
> To post to this group, send email to google-guice@googlegroups.com.
> 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 google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
