How to handle a shared object reference?

[Ken]

Hi. I'm doing a design using Java that has two hierarchies of
classes. Each hierarchy is defined by containment. So it's something
like:

class A contains an instance of B;
class B contains an instance of C;
class C contains an instance of D;

class A contains an instance of E;
class E contains an instance of F;
class F contains an instance of G;

So both hierarchies start with class A.

Using this example, classes D and G (the classes at the bottom of
these hierarchies) both use the same instance of another class. We'll
call that class SharedClass. D creates, writes to and reads from
SharedClass. G reads from and writes to the same instance of
SharedClass. However, each instance pair of D and G will share a
different instance of SharedClass. In other words, SharedClass is not
a Singleton.

My question is this: How do I make a SharedClass instance available
to both D and G? At first I was going to have A create the
SharedClass instance and have it work its way down to D through the
constructor parameters of B and C, and likewise get it to G via E and
F. However, that would let A, B, C, E and F touch this SharedClass
instance when they don't really need it.

Could someone recommend an alternative approach?

Thanks!

Ken

 

[VisionSet]

Hi. I'm doing a design using Java that has two hierarchies of
classes. Each hierarchy is defined by containment. So it's something
like:

class A contains an instance of B;
class B contains an instance of C;
class C contains an instance of D;

class A contains an instance of E;
class E contains an instance of F;
class F contains an instance of G;

So both hierarchies start with class A.

Using this example, classes D and G (the classes at the bottom of
these hierarchies) both use the same instance of another class. We'll
call that class SharedClass. D creates, writes to and reads from
SharedClass. G reads from and writes to the same instance of
SharedClass. However, each instance pair of D and G will share a
different instance of SharedClass. In other words, SharedClass is not
a Singleton.

My question is this: How do I make a SharedClass instance available
to both D and G? At first I was going to have A create the
SharedClass instance and have it work its way down to D through the
constructor parameters of B and C, and likewise get it to G via E and
F. However, that would let A, B, C, E and F touch this SharedClass
instance when they don't really need it.

Could someone recommend an alternative approach?

Well your design seems to be that A:SharedInstance is 1:1

So either do what you are doing or make SharedInstance a multiton, which
tracks its own instances in a Map keyed by instances of 'A'.

So a job for 'A' is to create these instances, then SI can get them.

I prefer your approach though. Seems that 'A' must do the instantiation
whatever.

 

[xarax]

Hi. I'm doing a design using Java that has two hierarchies of
classes. Each hierarchy is defined by containment. So it's something
like:

class A contains an instance of B;
class B contains an instance of C;
class C contains an instance of D;

class A contains an instance of E;
class E contains an instance of F;
class F contains an instance of G;

So both hierarchies start with class A.

These are not hierarchies as you've described them.
Hierarchy is a term for inheritance. You've indicated
that the classes CONTAIN AN INSTANCE. Therefore, this
is not "IS-A" relationship, but "HAS-A" relationship.

Using this example, classes D and G (the classes at the bottom of
these hierarchies) both use the same instance of another class. We'll
call that class SharedClass. D creates, writes to and reads from
SharedClass. G reads from and writes to the same instance of
SharedClass. However, each instance pair of D and G will share a
different instance of SharedClass. In other words, SharedClass is not
a Singleton.

My question is this: How do I make a SharedClass instance available
to both D and G? At first I was going to have A create the
SharedClass instance and have it work its way down to D through the
constructor parameters of B and C, and likewise get it to G via E and
F.

Start looking at the bottom (D,G) and see where these
instances are instantiated, then proceed upward. At
the point of divergence into "main stream" code, that's
where you add a constructor parameter for SharedClass.
Most likely, it is the constructor for A.

However, that would let A, B, C, E and F touch this SharedClass
instance when they don't really need it.

Instead of passing an instance of SharedClass from A
all the way through (D,G), instead pass an instance
of a SharedClassFactory object.

Could someone recommend an alternative approach?

Passing a factory object is a bit cleaner. The intermediate
classes can just pass the reference straight through to the
lower levels. At the lowest level, the constructors for (D,G)
can call the factory object to return the SharedClass instance.

The factory object should have an implicit reference to
the "A" instance that started the chain of instantiations,
so that when the factory is called to dispense an instance
of SharedClass, it can use it's internal reference to "A"
to obtain the same instance of SharedClass for both the
"D" and "G" constructors. You may also want to throw an
exception when the factory has already dispensed the same
SharedClass instance twice (once for "D" and again for "G").
Don't bother saving the factory instance. When the "D" and
"G" constructors are finished with it, let the garbage
collector discard it.

2 cents worth. Your mileage may vary.

 

[kk_oop]

Hi. I'm doing a design using Java that has two hierarchies of
classes. Each hierarchy is defined by containment. So it's something
like:

class A contains an instance of B;
class B contains an instance of C;
class C contains an instance of D;

class A contains an instance of E;
class E contains an instance of F;
class F contains an instance of G;

So both hierarchies start with class A.

Using this example, classes D and G (the classes at the bottom of
these hierarchies) both use the same instance of another class. We'll
call that class SharedClass. D creates, writes to and reads from
SharedClass. G reads from and writes to the same instance of
SharedClass. However, each instance pair of D and G will share a
different instance of SharedClass. In other words, SharedClass is not
a Singleton.

Based on everyone's input, here's what I'm thinking of doing.

I'm going to have class A implement an interface called
FamilyInstanceId. This will have one method called "getInstanceId"
which will look like this:

abstract public Object getInstanceId( );

Class A will implement it like this:

public Object getInstanceId( );
{
return (this);
}

So this basically returns an instance of the family owner class as an
object. All the classes in the chains below class A will have
FamilyInstanceId as a constructor parameter:

class B
{
public B(FamilyInstanceId anAFamilyInstanceId )
{
this.c = new C(anAFamilyInstanceId);
}
...
}
...
class D
{
public D(FamilyInstanceId anAFamilyInstanceId )
{
this.A_FamilyInstanceId = anAFamilyInstanceId;
}

I could then define SharedClass as what someone in this thread called a
"multiton." The multiton getInstance method would have a parameter of
FamilyInstanceId:

public SharedClass getInstance(FamilyInstanceId anAFamilyInstanceId);

getInstance would return the instance of SharedClass associated with
this particular family instance, e.g., the family under a particular
instance of A.

Doing this will enable any family member under a single instance of A to
access the family's shared instance of SharedClass. The nice thing
about this is that if additional shared classes are needed, they can
follow the same pattern, e.g.:

public SomeOtherSharedClass getInstance(FamilyInstanceId
anAFamilyInstanceId);

This scales nicely since it will avoid having to add additional
constructor parameters for additional shared class factories.

Also, other family's beyond this one can use the same approach, since
the name of the FamilyInstanceId class is generic.

Any thoughts?

Thanks,

Ken