Re: Using static factories to create two objects with bidirectional linking
- From: Sasa <sasa555@xxxxxxxxx>
- Date: Mon, 30 Apr 2007 07:36:34 +0200
kelvSYC wrote:
I seem to have trouble building a static factory due to the need to
build a two-way association:
Right now I'm making some kind of manager class, which, for a static
factory, takes two maps: one <A, B> and the other <B, C>. The manager
manages two types of objects: one is a wrapper for A (call it A'), and
the other is a wrapper for B (call it B'). A and A' have a one-to-one
relationship, as does B and B'. The manager has a one-to-many
relationship with A' and B'. (The two input maps are intended to be
discarded after the manager is built - for example, A and B are
"primitive input" like strings)
One issue is the need for a two-way relationship: A's and B's are
associated with their manager, so in order to create the A' for an A
the manager must first exist. But for the manager to exist it needs
all of the A's. This is a chicken-and-egg problem that I am unsure of
how to solve: If X and Y are two classes that are one-to-one with each
other, and an X and Y object are associated with each other, then
clearly both objects must be created at the same time. However, this
Almost - you cannot create both at the same time, you create first one then second, then connect them.
One way to do this is to construct Y in the constructor of X.
Alternatively, you could have some other factory class/method which creates both and connects them, but then both classes must have setters for instances of X/Y.
can only be done if one object was partially built, the other object
was built and linked to the partial object, and the partial object was
completed - which would imply that on one end there would be a public
interface to change the one-to-one association (making said
association no-longer one-to-one). How, then do I do this so that
this does not happen?
If you want to make one to one association imutable, you might consider the constructor solution (in the constructor of X you create Y providing it with the this pointer).
If this is not possible, you might used the alternative I suggested, but somehow hide the public interface for changing association. Ideally, only the factory class should be able to use this service to setup the association. You might do this by moving both classes to separate package, make some package only visible methods in both classes which allow you to setup association after the instances have been created and make public factory method.
This is not elegant, but it shields you from external users changing the association once it is established.
The other issue is in the construction of A' and B': beyond wrapping A
and B, I'd like them to have functionality that takes advantage of the
map - in A' I'd like to get the B's associated with it (determined
from whether the A is associated with the B), while in B' I'd like to
test whether an A is associated with this B' (which is done, of
course, through the manager link) and get the C associated with the
B' (determined from what C the original B is associated with). The
issue lies in how this is done, which I am stuck on.
What is a problem here?
If you have bidirectional association between manager and A' and manager and B' - both A' and B' objects can pass such queries to manager.
I'll try to rephrase your problem to describe how I understood it, based on your original post and response to HSL:
1. Manager holds associations to instances of other classes, and some other data about A' such as number of instances.
2. Hence at each moment the Manager must know about each existing A'
3. And A' must know about manager to ask him some questions (such as - which are my B's).
Did I understand that correctly?
Sasa
.
- References:
- Prev by Date: Re: Using static factories to create two objects with bidirectional linking
- Next by Date: Payroll Example with Source Code (OO vs P/R)
- Previous by thread: Re: Using static factories to create two objects with bidirectional linking
- Next by thread: Payroll Example with Source Code (OO vs P/R)
- Index(es):
Relevant Pages
|
