In other words you want an iron clad guarantee that objects are not
visible to the outside world until they have their links built.
Obviously for some short time they must be incomplete.  You can't find
out the address of B to feed to A before B exists and you can't create
B until you have the address of A.

If you promote A to Aprime it will get a new address, so staging by
using a builder object that gets converted when it is ready to the
actual object by a constructor does not look promising.

A reasonable but not unbreakable approach is to use a factory to
create a pair of objects.  You can make A and B abstract , or the
constructors private, hand out only an Interface and give the classes
themselves some horrible name.

You could have an "activated" boolean which is turned on when you use
the :
link ( A a , B b ) method tha builds both links.

You assert that boolean is turned on in crucial methods.

You could explicitly assert the link to the other is not null  in
crucial methods.

If they are so tightly coupled then why not create one instance in the
other instance's constructor?  As I said, it all depends on the model
you're trying to implement and the intended usage.

Regards

   robert

I have seen released code that requires an initialisation call after
every call to a constructor. In one or two cases the initialisation was
left out. It doesn't matter so much in a framework situation, where
there are many implementation and few places that construct.

For two object to have final references to each other the two obvious
solutions are make one an inner class of the other or create one in the
constructor of another.

You might want to step back a bit and decouple them slightly. Perhaps
one should add a listener to the other. Or perhaps it can be
restructured to introduce a third object that takes up aspects of both A
and B.

Tom Hawtin

+1 vote

java.io.PipedOutputStream
java.io.PipedInputStream

One cannot usefully exist without the other,

Richard