I can see your point here, I think it just speaks to the fact that I didn't explain my whole use-case scenarios. A Contact in my scenario really is an independent object. It can be created from a person scheduling an appointment. That act of scheduling an appointment would create multiple contacts that get stuffed into a queue. Each of those contacts might have a different method, a different message, a different everything. They get an email one week ahead of time with a confirmation link and then they get a phone call 48 hours ahead of time with a simple reminder. And there will be scenarios where a contact needs to get dropped in the queue that isn't associated with a person at all, it is just sending out an email or making a phone call to an arbitrary location.
My current application is actually designed more like what you are describing. I'm switching around the focus of the app from being person-centric to being contact-centric. Right now the app that sends out notifications (which might be a better word that Contact) has to figure out all the people that ought to get contacted right now, how they ought to be contacted, etc, when I run the app. That is a very expensive operation. It also means that it is problematic to show people ahead of time "this is who is going to be contacted when and how". And it means that if a client changes a preference (say, changes a notification from being 7 days ahead of an appointment to 10 days ahead) it can potentially miss notifying some of the appointments all together. So yeah, know you know far more about my application refactor than you probably ever wanted to know :) But I do appreciate your input a great deal, it makes me think about my application design which is always a good thing. Cheers, Judah On Thu, Nov 13, 2008 at 4:49 AM, Nando <[EMAIL PROTECTED]> wrote: > > 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
