Class Analysis

[RV76]

I am trying to find out if it is better to not create a class for customer contacts. For example, a customer may have 1 or many customer contact. The only operations that I can think of are add a new customer contact, modify a customer contact, getCustomerContact. The attributes include things like contact first name, last name, phone, etc...

Also if an invoice have line items, I am assuming it is not better to have a class called lineitems.

 

[cpjust]

Sounds like you might want a list of customer contacts then.

 

[stevexff]

In both the examples you cite, they are compositions, (i.e. they are parts of another object). A contact can't belong to more thsn one Customer, and a LineItem can't belong to more than one Invoice. You definitely need a Contact object. Your Customer object has a collection of Contact objects, so you can create new Contacts, add them to the collection, sort them etc.

Make sense?

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[BobRodes]

I agree with steve. And I also agree with cp. I would think about having a contactlist object that is composed of none to infinite contacts. The contactlist object (cp's "list of customer contacts", steve's "collection of contact objects") would be in a composition relationship with the customer object, with a multiplicity value of one and only one, and would expose as methods the functionality that steve describes (add contact, sort).

Bob