I have to point out for the assembled gallery that this is almost verbatim a textbook example of where not to use inheritance. What happens if an agent is also an employee? Or a user is an employee of more than one firm? No doubt for Adrian's use case this isn't a problem - in fact the restrictions inherent in this model may be actually what he's needing to represent - but at face value this kind of model should ring alarm bells.
The more conventional way to model these concepts is to say they are all properties of a relationship between a user and an organisation. So customerOf, employeeOf, agentFor would all be properties of User, not subclasses. They will likely also be objects in their own right, with intrinsic validation rules. You still might need a strategy to deal with the parent User object, but not necessarily to cope with the relationship properties. Jaime Metcher > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] Behalf > Of Adrian J. Moreno > Sent: Saturday, 24 November 2007 6:05 AM > To: [email protected] > Subject: [CFCDEV] Re: Bean Validation and the State pattern > > > > We have 4 user objects: > > User.cfc > Customer.cfc (extends User.cfc) > Agent.cfc (extends User.cfc) > Employee.cfc (extends User.cfc) > > The base User object has 5 properties, the subclasses each have a > different set of properties. All of these beans are "dumb". > > I think our process matches the Strategy pattern more than anything else. > > We have a UserRegistration.cfc to validate data when a new Customer or > Agent is signing up. The validation routine differs based on the type of > policy a Customer has or the type of Agent that's signing up. > > 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(). > > After the Registration object validates data on a new user, the user > object is passed to the appropriate {UserType}DAO.create() method. > > When changing a user's data, the user object is run through > UserRegistration.validate() before it's passed to {UserType}DAO.update(). > > HTH, > > Adrian > > > Alan Livie wrote: > > I am working on validation for my User cfc. On different parts of the > > site when users register different criteria are asked for. > > > > ie we offer a quick registration process where only email, username > > and password are mandatory. There is also a full registration where > > additional fields are mandatory. There will also be a third situation > > where different fields are mandatory if they are on the American > > version of the site, also slight changes for the German site. > > > > I thought that rather than have all the conditional code inside the > > bean that will constantly need tweaked I would use either State or > > Strategy pattern. > > > > State makes more sense to me and would create an abstract class (cf7 > > at the mo so no interfaces) called UserValidationState which would be > > subclassed by QuickRegValidation.cfc, FullRegisterValidation.cfc, > > QuickRegValidationUS.cfc etc etc and compose these concrete CFC's > > using the State pattern. > > > > I have a little bean factory that will create and compose the cfc's > > when a User object is created. Either client code or a service cfc > > will determine the state the object will be in when it is created. > > > > I'm interested in how others would approach it. > > > > Is using State the best way to do this or does Strategy make more > > sense (or something else I haven't thought of)? > > > > Lots of if statements in User.cfc is the one thing I don't want! > > > > Thanks > > > > 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 -~----------~----~----~----~------~----~------~--~---
