Yes, and I'm still wary of using inheritance in this way because of the inflexibility it imposes. I've gone down this route several times and not liked the result.
What makes more sense to me is have a Contact represent the person with a property of contactPreference (to get away from the concept of "type" for a moment). According the the contactPreference, either a EmailContactAction, a PhoneContactAction, or an SMSContactAction object is created. The Person, or Contact in my way of naming things, knows the contactPreference, but doesn't execute the specific ContactAction. That seems more flexible and "right" to me. Whether or not an abstract ContactAction is needed is then a simple decision of grouping properties, but it still seems wrong to me that a property in an abstract class is used to decide which subtype to instantiate. But hey, who am I? Go for it if it makes sense to you. On Thu, Nov 13, 2008 at 6:16 AM, Jaime Metcher <[EMAIL PROTECTED]> wrote: > > I suspect Nando is thinking "contact" = "person", whereas you are talking > about an action of contacting someone. Sound right, Nando? > > Jaime > >> -----Original Message----- >> From: [email protected] >> [mailto:[EMAIL PROTECTED] On Behalf Of Judah McAuley >> Sent: Thursday, 13 November 2008 2:41 PM >> To: [email protected] >> Subject: [CFCDEV] Re: Is inheritance the right choice here? >> >> >> 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 >> >> > >> > > > > > > -- Nando M. Breiter The CarbonZero Project CP 234 6934 Bioggio Switzerland +41 76 303 4477 [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
