unidirectional vs bidirectional association
Hi,
I've read lots of examples and it seems to me that, in reality, these are bidirectional associations:
Employee and Department (given an employee, you can find out what department(s) s/he belongs to; given a department, you can find out which employees are in it)
Parent and Child (given a parent, you can find out who are his/her children; given a child, you can find out who his/her parent(s) are)
Bid and Item (given a bid, you should be able to tell which item it is for; given an item, you can tell which bids were made on it).
To show unidirectional, the author just omitted the reference to the other in one class. In my opinion, all of the above should be bidirectional (in real life, they would be, I think).
Can someone give me some real life examples of a unidirectional association?
Are most associations bidirectional?
Thanks,
C
[906 byte] By [
cloraca] at [2007-10-3 4:09:38]
> Hi,
>
> I've read lots of examples and it seems to me that,
> in reality, these are bidirectional associations:
> Employee and Department (given an employee, you can
> find out what department(s) s/he belongs to; given a
> department, you can find out which employees are in
> it)
> Parent and Child (given a parent, you can find out
> who are his/her children; given a child, you can find
> out who his/her parent(s) are)
> Bid and Item (given a bid, you should be able to tell
> which item it is for; given an item, you can tell
> which bids were made on it).
>
> To show unidirectional, the author just omitted the
> reference to the other in one class. In my opinion,
> all of the above should be bidirectional (in real
> life, they would be, I think).
>
> Can someone give me some real life examples of a
> unidirectional association?
> Are most associations bidirectional?
You're quite correct - in "real" life, relationships like the ones you cite are bidirectional.
However, that does not mean that every software representation of real life situation require the bidirectional relationship. If the model you've derived has no need of the many-to-one inverse relationship, it's possible to leave it out. Why do it? If the model doesn't require it, looser coupling.
If I'm modeling a parent-child relationship in a financial application, the parent has to know about child dependents, but there might not be any reason for the child object to know who their parent is. I only navigate to children objects by accessing the parent first.
%
Yes. Most of them are bidirectional.
But if you have a Composition relationship, where ClassB is controlled entirly by ClassA, then you may see some unidirectional relationships (Unless your application logic need anything else).
For example Order and OrderItem. Order knows about its items but the item belongs to one particular order, so we may omit this. Similarly Student and StudentAddress (A student have many home address, other contact address etc.)
