This probably isn't ideal, and I don't know if you can control how the
RobotModule gets added to the injector, but you can wrap RobotModule in a
PrivateModule:
public static class PrivateRobotModule extends PrivateModule {
@Override
protected void configure() {
install(new RobotModule());
bind(Robot.class);
expose(Robot.class);
}
}
If you use that instead, the RobotHeart binding won't be exposed. Then you
can do:
public static class TitaniumRobotModule extends PrivateModule {
@Override
protected void configure() {
install(Modules.override(new RobotModule()).with(new AbstractModule() {
@Override
protected void configure() {
bind(RobotHeart.class).toInstance(new RobotHeart("titanium"));
}
}));
}
@Provides @Titanium @Exposed
protected Robot provideTitaniumRobot(RobotHeart heart) {
return new Robot(heart);
}
}
This seems to work for this example, anyway. I don't think it would require
the provider method if an interface were being exposed rather than the
concrete class.
Colin
On Tue, Feb 9, 2010 at 11:42 PM, Evan Gilbert <[email protected]> wrote:
> Thanks for the suggestion...
>
> On Tue, Feb 9, 2010 at 3:24 PM, Brian Pontarelli <[email protected]>wrote:
>
>> On Feb 9, 2010, at 12:43 PM, Evan Gilbert wrote:
>>
>> > Trying to solve a use case in Guice that's similar to Robot Legs, but
>> the existing solutions don't seem to map.
>> >
>> > Use case (code below):
>> > - Have an existing Robot class with @Injected constructor that takes a
>> RobotHeart
>> > - Have existing RobotModule that provides a set of bindings for robot
>> parts, including a binding for RobotHeart
>> > - Can't modify RobotModule or Robot
>> > - I want to be able to inject a Robot instance with a different
>> RobotHeart binding, i.e.
>> > @Inject @TitaniumHeart Robot;
>> > creates a robot with a different injected heart.
>> >
>> > The PrivateModule solution doesn't seem to work, because it would create
>> a duplicate key for RobotHeart.class and duplicate keys aren't allowed.
>> >
>> > Any thoughts on how to implement?
>>
>> Doesn't subclassing work? What issues are you having with that type of
>> solution?
>>
>
> Subclassing can probably work for my use case but I would prefer not to if
> there are alternatives:
> - It's fragile and more likely to break when the parent class changes
> - Won't work with deeper injection trees - you have to subclass the whole
> tree above the injected class. So if a Robot has a RobotLeg with a RobotFoot
> with RobotBigToe and I want to provide a different big toe, I have to
> subclass Robot, RobotLeg, and RobotFoot.
> - It also seems to be a bit counter to the spirit of injection.
>
> But... this may work and I'll probably move forward with it if there aren't
> other alternatives.
>
>
>> -bp
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "google-guice" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<google-guice%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-guice?hl=en.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<google-guice%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" 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?hl=en.
