also consider simply
class A {
@Inject A( B b ) {
b.setA( this );
}
}
Unless you really need to pass A to B's constructor.
-d
On Apr 17, 5:51 pm, "Dhanji R. Prasanna" <[email protected]> wrote:
> Yea I was afraid of that. Well you could resort to setter injection and
> write a @Provides method:
> @Provides A get() {
> A a = new A();
> B b = new B(a);
> a.setB(b);
> return a;
>
> }
>
> Dhanji.
>
> 2009/4/18 Olivier Grégoire <[email protected]>
>
> > Thank you for that answer, however I may not use them as singletons, since
> > they logically are not (well, I must keep track of several A's).
>
> > I tried to simplify the problem and removed all interfaces (because I
> > thought they weren't useful in the problem presentation), but basically, I'm
> > indeed managing interfaces, and not concrete classes, and therefore a proxy
> > suits very fine. The "identity equality" comment was not to show that I
> > require it, it meant more that I want to speak about a logically same
> > instance, not two different instances created by Guice.
>
> > Is the behaviour that you describe applicable to other instances than
> > singletons, even with some additional code (without having to create the
> > proxy myself though)?
>
> > Any other suggestion? If no, I'll keep on going with the AssistedInject.
>
> > Olivier
>
> > 2009/4/17 Dhanji R. Prasanna <[email protected]>
>
> > It looks like you are talking about a circular relationship. If you mark
> >> both as singletons and hide the dependency behind an interface, Guice will
> >> automatically generate a proxy to hook this up for you.
> >> You won't get identity equality (one will be a proxy), but the circular
> >> relationship (1:1) will be maintained in effect.
>
> >> Dhanji.
>
> >> On Sat, Apr 18, 2009 at 12:25 AM, Olivier <[email protected]> wrote:
>
> >>> Hello,
>
> >>> I would like to create a 1 to 1 relationship between two components.
> >>> Here is the "old-fashion" code that represent what I want to have.
>
> >>> import static org.junit.Assert.*;
> >>> import org.junit.Test;
>
> >>> public class OneToOneRelationshipTest {
> >>> static class A {
> >>> final B b;
> >>> A () { this.b = new B(this); }
> >>> }
> >>> static class B {
> >>> final A a;
> >>> B (A a) { this.a = a; }
> >>> }
>
> >>> �...@test public void testOneToOneDependency() {
> >>> A a = new A();
> >>> assertEquals(a, a.b.a); // check identity
> >>> }
> >>> }
>
> >>> I've thought about using AssistedInject to transfer a factory of B to
> >>> A:
>
> >>> import static org.junit.Assert.*;
> >>> import org.junit.Test;
> >>> import com.google.inject.*;
> >>> import com.google.inject.assistedinject.*;
>
> >>> public class OneToOneRelationshipWithGuiceTest {
> >>> static interface Factory { public B create(A a); }
> >>> static class A {
> >>> final B b;
> >>> �...@inject A (Factory f) { this.b = f.create(this); }
> >>> }
> >>> static class B {
> >>> final A a;
> >>> �...@inject B (@Assisted A a) { this.a = a; }
> >>> }
> >>> static class Module extends AbstractModule {
> >>> public void configure() {
> >>> bind(A.class);
>
> >>> bind(Factory.class).toProvider(FactoryProvider.newFactory
> >>> (Factory.class, B.class));
> >>> }
> >>> }
>
> >>> �...@test public void testOneToOneDependency() {
> >>> A a = Guice.createInjector(new
> >>> Module()).getInstance(A.class);
> >>> assertEquals(a, a.b.a); // check identity
> >>> }
> >>> }
>
> >>> However I'm wondering whether this is "too much" or not because my
> >>> expectations are quite simple, but I feel like a more simple @Provides
> >>> can help me. I just don't know how I could correctly modelize it,
> >>> because I didn't see an example on the wiki.
>
> >>> Can anyone help me getting rid of AssistedInject if possible?
>
> >>> Olivier
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---