The key here is the separation of role from party (person or organization) because a party may have multiple roles at a time or over time. Consider what happens when someone is promoted: if you use inheritance to model them (manager is-a user) then you have to change the object's type in order to promote them. That should raise a red flag. If you separate the role out, it should be clear that the person remains the same but their role changes, i.e., promotion is just a matter of changing their 'role' attribute.Early this year I worked with a very large bank that had the security model built around titles. This allowed them to have a very rigid security framework because it never changed. Sure people's titles changed, but what the title could do never did.
Without debating the merits of this model since it was driven by HR as opposed to IT, it becomes clear that assumptions people make in regard to OO design can be wrong depending on context. In the case of the bank I mentioned, the shear elegance of having an object model map directly to the existing business's model was hugely valuable.
Matt Liotta President & CEO Montara Software, Inc. http://www.MontaraSoftware.com (888) 408-0900 x901
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
