Re: IoC, DI, and a mess...
Daniel Pitts wrote:
Basically, I'm going to have any number of robots that are differently
configured, and the configuration is depending user interaction.
(Basically, the user writes a definition about the robot. The format for
this definition can *not* be changed)
This kind of configuration seams to be something beyond current release
of Guice. However, there are some workarounds possible:
1) Bind configuration parameters as a named (or, better, "enumed")
constants (see: @Named). This requires a separate injector for each
distinct configuration option set (binding must be performed before
first instantiation), but is probably the best choice in sense of
loosely coupling of a components.
2) Create (or generate, using e.g .'AssistedInject' technique) a
custom factory for a parameterized objects (see "How do I pass a
parameter when creating an object via Guice?" at
http://code.google.com/p/google-guice/wiki/Guice10Recipes).
3) Store configuration before instantiation in e.g. ThreadLocal, and
access it during injection everywhere where needed (for example in
fields' initializers). Unfortunately, it's not easily applicable when
reusing some scoped objects (e.g. bound in Scopes.SINGLETON).
4) Apply additional parameters after instantiation performed by
injector. Appears to be a rational choice in your case.
So, unless I'm missing something, this doesn't seem to be a good fit.
Well, none of the above listed workarounds is perfect. But it seams
that benefits from DI performed by Guice in other cases (circular
dependencies, scopes etc.) are still worth the effort in finding the
best method of applying an extra configuration options.
To measure it somehow, I created a model based on the code fragment
posted by you -- just making your configureRobot() compilable, and
running without errors. After that I added @Inject to each setter and
constructor of the model classes. And after instantiation a robot with:
Robot robot = injector.getInstance(Robot.class);
where injector was made without any module (just a default Guice
bindings); a post-configuration, which I think is similar to your
original one, looks as follows:
void configure(Robot robot) {
robot.getHeat().setCoolMultiplier(
chooseDoubleFor("heatsinks", 0.75, 1.00, 1.125, 1.25, 1.33, 1.50));
robot.getTurret().setKeepshift(false);
}
Other stuff from previous configuration was performed by Guice.
But, of course, the choice is yours. :-)
piotr