Silly Question on OOD

[Roger Zacharias]

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]

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]

Thank you Noel!
Roger

[rethna pillai]

Can we show these assoication as an aggregation.?

[noel angel]

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]

Ratha,
By the way: no one does it that way either. Remember that aggregation IS a form of association.
Noel

[Roger Zacharias]

>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]

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