• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Silly Question on OOD

 
Roger Zacharias
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi SCEAs and SCEAs to-be!
Another question, which seems very simple but on which I am very uncertain:
Imagine you have two classes, e.g. Customer and CreditCard and the Customer can only have one CreditCard. So you have an 1:1 association "owns" between Customer and CreditCard and navigability in both directions.
I am uncertain if I have to show the customerID as an attribute to CreditCard or if this is done implicit???
What do you think?
Roger
SCEA to-be
 
noel angel
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rodger,
First, I don't think you will want navigability going both ways. Which transactions would start with a credit card object? Many will start with a customer object. It is reasonable to associate a credit card with a customer. An association implies that the cutomer object holds a reference to the credit card object in the customer object as a member.
Also an order object may associate customer and implicitly the credit card object together with order items or something else....
Also, having the navigability go both ways has implications for the design of the dv schema. It is more expensive to provide all the additional keys for bidirectional associations.
There are cases where bidirectional relationships are necessary. These are often many to many relationships which require an association class and a extra db table to support.
Noel
SCJP, SCWCD, SCEA(Part1)
 
Roger Zacharias
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Noel!
Roger
 
rethna pillai
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can we show these assoication as an aggregation.?
 
noel angel
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ratha,
It would technically be correct but if you start down that path: Customer has a credit card and customer has an address what will happen is you will discover that the entire system is a "has a" relationship. You will lose a lot of information that associations provide. Hence, this is one of the arguments for using only associations in a class diagram!
Noel
SCJP, SCWCD, SCEA(Part 1)
 
noel angel
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ratha,
By the way: no one does it that way either. Remember that aggregation IS a form of association.
Noel
 
Roger Zacharias
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>First, I don't think you will want navigability going both ways. Which >transactions would start with a credit card object? Many will start with a >customer object. It is reasonable to associate a credit card with a >customer. An association implies that the cutomer object holds a reference >to the credit card object in the customer object as a member.
Hi Noel,
ok we have Customer ---> CreditCard and:
class Customer {
String custID;
String name;
String address;
...
Collection creditCards;
}
and
class CreditCard {
String ccID;
String number;
String type;
}
OK?
But in the DB schema you have the foreign key "custID" in the CreditCard table and no foreign key in the Customer table. So its a kind like
Customer <--- CreditCard.
I am right?
Roger
 
noel angel
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rodger,
Yes, you are correct but I still maintain that you would not need to traverse the relationship from credit card to customer.

Noel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic