On Nov 25, 2013, at 9:45 AM, Christian Gruber <[email protected]> wrote:
> On 25 Nov 2013, at 5:51, Brian Pontarelli wrote: > >> 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. > > If you are arguing "constructor injection is better for these reasons" that > is fine - you find those reasons to be more of a value traded-off for the > value of brevity, etc. I don't think it's nearly so certain a win, but I've > not met many developers who aren't "absolutely certain" that their choice > between field and constructor injection is "the right way". So take from > that what you will. Personally, I find constructor injection to be a slight > win, where you can do it. You are correct. These items are what cause me to favor constructor injection because I use them daily. I use mocks to test my code and prefer to use the constructor to pass in my mocks instead of a package-protected field. It forms a contract that makes it easier for me to test using steps like this: I instantiate the object I’m testing. If the compiler complains, I create mocks for each constructor argument until they are all mocked. Then I setup the mocks and test. Since everything in my system follows this pattern, I often look at constructor parameters to build mental graphs of my objects. It also allows me to capture instantiation events from Guice and do additional work. I also don’t have to reference a dependency, if it is only needed in the constructor. If none of those things matter to you, then it would be more likely a coin toss on which to use. > >> 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. > > And again, I don't think field injection advocates are saying those are all > illusory, I think they're saying that in their "lived experience" (so to > speak) they simply don't find these advantages to actually catch very many > bugs, prevent very many bugs, nor communicate intent any more intentionally > or clearly than the other signals with field injection. In short, they can > all agree with this statement and still not care. Because it is a trade-off > between advantages, and those comparisons and valuations are subjective. I see what everyone is saying, I can agree that in practice, it rarely occurs that field injection gets mis-used or causes bugs. Though, if you add setters to the equation, all bets are off. I do believe there are more benefits than simply reducing bugs though. — Brian -- 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.
