Thanks everyone. @Paul, you said:
> Maybe I'm misunderstanding, but I would think that the User would be a > transient (created for the duration of the request) object rather than > a singleton. You can use setter rather than constructor injection > either way. > Sorry, I didn't explain it well. User is transient. I was trying to say that my main reason for using setter injection was simply for continuity. I use setter injection for my Singletons using Coldspring so I'm sticking with this approach for all object composition. @Adrian, you said: > We pass the user object to UserRegistration.validate( User ) first and > that method determines whether to call validateCustomer() or > validateAgent() based on user type. Then we have a bunch of subroutines > to break down the business logic like validateDriverLicense() or > isMasterAgent(). > This is sort of the idea I'm going with but I want each validation method in seperate cfc's so its less risk adding new validations for different versions of the site. ie if I have to do something different for the French site then I can create a new subclass cfc so all my other validation cfc's are untouched - I think this is called the 'open-closed principle' - and I like deploy days to be as stress-free as possible so deploying a new cfc is much preferrable to constantly deploying one that affects everyone :-) @Jamie - I agree with everything you say. I try to avoid inheritance for these reasons and try to always go with composition unless I'm 100% sure that business rules will not change and I know inheritance will not give me headaches down the line. One thing I will say is once I have the various validation cfc's working properly I will push common behaviour from them all up to the parent Strategy cfc or possibly in the User bean itself (haven't decided the best approach on this yet - I like the idea of objects validating themselves but with a lot of validation delegated to the Strategies it may make more sense to move all common validation for users into the parent Strategy cfc - this would mean the parent Strategy isn't abstract anymore but I don't see this as a problem. Alan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
