On Sep 22, 2009, at 9:07 AM, Anjo Krank wrote:
My argument being, I have a lot of code that depends on various
"services" and their instantiation. But 90% of the time, this code
depends on user input, program state and external stuff. It's very
rare that I actually know at compile time what implementation I
have. We normally use Class.forName().newInstance() in some way or
other to handle that. So can DI help me there? If yes, how?
DI is just an environment to help you with your interface-based
design. Nothing prevents you from writing a dynamic strategy-based
service. At the same time DI it can simplify the public API of your
services in many cases by removing environment-specific arguments from
your method signatures. E.g.:
ERXSQLHelper sqlHelper = ERXSQLHelper.newSQLHelper(ec,
model.name());
ERXSQLHelper sqlHelper = ERXSQLHelper.newSQLHelper(ec, dbc);
ERXSQLHelper sqlHelper = ERXSQLHelper.newSQLHelper(ec,
channel);
may become
ERXSQLHelper sqlHelper = sqlHelperService.newSQLHelper(model.name());
ERXSQLHelper sqlHelper = sqlHelperService.newSQLHelper(dbc);
ERXSQLHelper sqlHelper = sqlHelperService.newSQLHelper(channel);
So here you don't need to pass ec to the method as it is injected in
sqlHelperService behind the scenes. This means that you don't need to
carry over all needed parameters through the call chain, just to pass
it down to some method. It creates some really nice refactoring
opportunities, and again - it reduces coupling of the public API.
I should say I didn't get DI in theory until I tried it. Just like
many programming optimizations (say OO vs. procedural) this is about a
better abstraction which is not really obvious until you start using it.
Andrus
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
