Comment by [email protected]:
Really bad explanation.
If you use a private constructor now your classes depends on the DI
framework, they are more difficult to test: how do you write an unit test
for DatabaseDataReader without using Guice or other framework that supports
the @Inject annotation? The answer is to put the unit tests in the same
package, but sometimes you want to make unit test for other classes in the
same project module (but in other package) that use the implementation, yes
you can use mock objects but an abuse of them also makes unit test
difficult to maintain.
* _make refactoring more difficult._
_Why?_ Show me a case where refactoring is more difficult because of the
constructor.
* _break the interface-implementation abstraction barrier._
What do you mean with that? You are writing an implementation, making the
constructor private doesn't make the dependency to disappear. Is bad if the
dependency is on the interface, but for the implementation hiding the
dependency behind a framework feature only makes things worst.
* _introduce tighter coupling within a codebase._
Non sense, if you use a private constructor your class is coupled with
an @Inject compliant framework
_As a simple, mnemonic remember that public and @Inject are like Elves and
Dwarfs: they can work together, but in an ideal world, they would coexist
independently._
LOL good luck when you want to use your implementation in other project
that doesn't use Guice
For more information:
http://code.google.com/p/google-guice/wiki/KeepConstructorsHidden
--
You received this message because you are subscribed to the Google Groups
"google-guice-dev" 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-dev?hl=en.
