Kevan,

> Right, the methodCode/contactType string is actually coming 
> from the db and is used to create the object. That's what I 
> was trying to get at above :). 

Oh, I see.  Yes, there are certainly some use cases where this is the best
solution.  I would avoid it wherever possible as it makes code much harder
to read, but if you really need rapid reconfiguration and can justify the
maintenance overhead, that's a reasonable way to do it.
 
> The if block approach seems good for handling type/object 
> logical mappings during object creation, but I also had in 
> mind another scenario - suppose you have a common set of 
> files for each type:
> EmailContact.cfc, EmailContactValidator.cfc, 
> emailContactForm.cfm PhoneContact.cfc, 
> PhoneContactValidator.cfc, phoneContactForm.cfm 
> SMSContact.cfc, SMSContactValidator.cfc, smsContactForm.cfm
> 
> At the moment I can only think of using the naming convention 
> approach to prevent duplicating the if block where each of 
> the files is used.
> Any suggestions in this case?
> 

Still only one if block.  Without imputing a fully fleshed out model from a
pretty sketchy scenario, the general approach is that you end up with a
factory object that can give you all the bits you need.  The one if block is
needed at the point you instantiate the factory object.  A very simple
approach is to make the Contact the factory for all the other objects
(validator, form etc) (this is a poor design in some respects, but it
illustrates the priniciple.

Jaime



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

Reply via email to