-
1. Re: Qualifiers vs concrete implementations at injection points
pgmjsd Jun 26, 2011 9:30 AM (in response to wujek)
Wujek Srujek wrote on Jun 25, 2011 05:34:
Now, I haven't been able to understand yet, why is @Inject with a qualifier that is bound to a concrete implementation better than simply @Inject with the concrete implementation itself.It is 'better' if you value decoupling and implementation hiding. The client code only depends on the interface and the qualifier annotation. This is a 'simpler' design from the dependency perspective, but ... as you said it might be confusing to junior engineers.
The only point I see is that if you inject the concrete impl without qualifier, you might accidently use methods of the impl.And that will strongly couple the client code to the implementation, which may end up being a very bad thing down the line.
If you really want to be modular, put the interface, all the transfer objects, and the qualifier in an 'api' module. Then your modules have a logical and clean dependency graph.
I guess; passing objects like this seems to violate the Law of Demeter) and these other classes might use impl-specific methods, not just the interface methods. Then, if you do decide to change the implementation, you can get compilation errors for such methods, because they existed for PayPal, but it is no longer true for Cash. Having said that, testing and mocking would show this problem, and since you have to recompile anyways, I am not sure if it's a big deal.It depends on the value decoupling and modularity provides going forward. For example, if you think that you'll be adding new payment methods, or perhaps deciding which payment method to inject at runtime, then using an interface will provide some benefits.
As far as re-compiling things go, I'm not sure why that is important in this age of fast compilers and automatic build tools like Maven. As I had mentioned before, if you give the API it's own module then you get some de-coupling, which should allow a more parallel development effort.
Like I said, it all depends on whether the de-coupled, modular design is valuable to your situation. It isn't always the case.