Any way to override bindings?
Ben
We have a parent project and a child project. The child project is a
customization of the parent project, where some of the interfaces in
parent project will have different implementation classes.
What I was thinking that we could do was to subclassing a Module as:
parent project:
class MyModule extends AbstractModule {
protected void configure() {
bind(Interface1.class).to(Class1.class);
bind(Interface2.class).to(Class2.class);
...
}
}
child project:
class SubModule extends MyModule {
protected void configure() {
super.configure();
bind(Interface2.class).to(Subclass2.class);
}
}
This way I'm hoping that sub module will use almost every setting in
parent project with the implementation class of Interface2 changed to
Subclass2.
But if I'm not mistaken, Guice isn't happy about this. An interface
can only have one bindings.
I'm trying to think of a workaround or a better solution. At the same
time, hope some of you guys may shed some light for me.
Ben.
Robin Sheat
> I'm trying to think of a workaround or a better solution. At the same
> time, hope some of you guys may shed some light for me.
useful for me also. The way I was thinking of doing was just to have a
'base' module, and then a 'fork A' subclass and a 'fork B' subclass
with the different bindings in them, but it is a bit
less flexible.
Cheers, Robin.
Kevin Bourrillion
In your case, instead of a hierarchy of modules, all you need is for your modules to be more granular. Modules should be atomic; a grouping of bindings that an application is likely to want either all of or none of.
I hope this helps.
K
Ben
Theoretically I like the idea of making everything granular enough so
that no overriding is needed. That makes everything simple.
Yet practically I do not know an elegant way of doing this.
There is no rule for what the sub project can subclass or override
currently. The overriding is really adhoc, in that the owner of
sub-project can choose to customize all of the 327 interfaces the
parent project has.
The only way I can think of is to make every "bind" an individual
overidable method:
class MyModule {
protected void configure() {
configureType1();
configureType2();
...
}
void configureType1() {
bind(Type1).to(Class1);
}
void configureType2() {
bind(Type2).to(Class2);
}
}
Personally I hate this design (make everything abstract because you
never know if you need to override it). And it does end up with a lot
more code.
I can see we may be able to live with the "no default impl resolver",
but not being able to override (or an equivalent workaround) will be a
big pain for us, if not a show-stopper to my proposal of using Guice.
Ben
is it worth maintaining it for bindings within a module?
What do you think if Guice does not blow away when a binding is
overriden by the same module object that created it? Implementation of
this shouldn't be too hard ( by wrapping the Binder object with the
Module reference before passing it to the Module.configure(), and
keeping the reference of source Module in the binding.)
Ben
annotatedWith(), as this creates different Key.
Feels like it is unavoidable to replicate some logic in Guice to make
this MyModule thing work.
Also, is custom API needed? I was thinking of a set of decorators on
Binder, LinkedBindingBuilder etc..I want to avoid telling my team
mates that: Yes, we are using Guice. But this in-house abstraction
layer on top of it is necessary because of blah blah blah.
Dhanji R. Prasanna
Hmm. then this custom API will also need to take care of things like
annotatedWith(), as this creates different Key.
Feels like it is unavoidable to replicate some logic in Guice to make
this MyModule thing work.
Also, is custom API needed? I was thinking of a set of decorators on
Binder, LinkedBindingBuilder etc..I want to avoid telling my team
mates that: Yes, we are using Guice. But this in-house abstraction
layer on top of it is necessary because of blah blah blah.
if you impl the guice binder interfaces they wont need to know (except that you have broken the contract for modules--i.e. rebinding allowed). That ought to be made clear in any event.
Ben
> you have broken the contract for modules--i.e. rebinding allowed). That
> ought to be made clear in any event.
>
My feeling is that we can take the "no rebinding" rule as imposed by
the default Guice Binder interface.
And we could create a RebindableBinder decorator that wraps a Binder.
And that is quite explicit.
Dhanji R. Prasanna
Sure, either way I suggest you impl the Binder interfaces for compatibility. and explicitly state the breaking of contract. It is not a cardinal sin to break the contract with a sub-type override if you make it clear.
java.sql.Date comes to mind.
Btw, is it only the binder that enforces the no-rebinding rule? Can we use the default impls of say AnnotatedBindingBuilder etc?
Ben
> Btw, is it only the binder that enforces the no-rebinding rule? Can we use
> the default impls of say AnnotatedBindingBuilder etc?
Ben
the same module.
Have to say the impl is not trivial. Used quite some dynamic proxy
tricks. (including using http://dimple.codehaus.org)
Will share it after some polishing.
Ben
This impl depends on http://dimple.codehaus.org to avoid versioning issue in decorating Guice interfaces such as Binder, AnnotatedBindingBuilder etc. (I could create decorators directly and generate delegate code using Eclipse, but the code will not compile should more methods are added to these interfaces in the future, which I consider quite possible.)
Anyway, by extending from OverridableModule, binding overriding is supported. The use of OverridableModule is exactly the same as AbstractModule.
