On Wed, Nov 12, 2008 at 5:51 PM, Nando <[EMAIL PROTECTED]> wrote: > > I wouldn't do it this way, simply because I couldn't ask a phone > contact for its email address, and visa versa. It also seems a little > contrived that the either of the contact types don't know what their > type is until another entity (the database, in this case) makes an > informed choice. Contact type seems more of a property of a Contact. > Why create that barrier?
This is the sort of thing I'm trying to wrap my head around. In my UML, I do have a contact method property which would tell me to go look for email properties or phone properties. Or down the road, sms properties, etc. > Not knowing more about the context of your application, you may be > better off modeling the real world. If you ask a phone contact over > the phone for their email address, they know it. If you ask a contact > when they walk in the door if they phoned or emailed their order in, > they can tell you. The context is this...I've got a scheduling application that says "I need to contact this person about their appointment 2 days ahead of time". So I am going to stick a contact request into a contact queue at a slot 48 hours before the time of their appointment. But each person will have a preferred contact method. Some messages might go out via email, some might go out via a text to speech phone call, etc. My design principle is that the queue process shouldn't care about the details of a contact other than what it needs to know for the queue. It needs to know when the earliest time it can send out that message is and when the latest it can send it out. Then when its time, it dispatches the contact off to the handler that will do the notification. That handler doesn't need to know anything about time windows, etc, it just needs to know what kind of contact it is and then delegate to the handler that deals with a specific contact type. Email, Phone, etc. > You could take the same approach with any number of properties, > creating separate objects for MaleContacts and FemaleContacts for > instance, or what about AdultContacts and ChildContacts? Now what do > we do about a FemaieAdultPhoneContact? I guess I kind of think of the EmailContact object as being a sub-object of a Contact object. A Contact is a package of sorts that has some common information and then has other info tacked on by its sub object. Each Contact, though, would have to have one and exactly one sub object. It would have to have an email sub-object or phone sub-object. And with that setup, I suppose I could see making EmailContact and PhoneContact their own top-level objects, but then I'm duplicating properties. > Sorry for belaboring the point. It's late at night here in Switzerland ;-) I can use all the belaboring I can get while I go from theory to practice in OO-land. Cheers, Judah --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
