While I dont know the exact situation - and what you want to achieve with all the different objects from within Coldfusion - there is another OO pattern that you did not mention and that is one of Interfaces (and Implements).
It could be possible to have totally discrete classes to handle all the validation and handling details of each - but have each Implement an Interface that provides all the basic user functionality.
However, Coldfusion doesn't support Interfaces (although I have seen a few attempts to provide them). But an Interface is just a contract of the methods a class provides. So, as long as you document that your classes Implement a certain Interface, then you can be sure that instances of those classes will have the necessary methods for you to call when you need the generic information.
Inheritance may work by having a "BasicUser" class and then inherit from that for the specialisations.
Composition and Inheritance could still be used by having your basic class provide a "detail" method (as well as overriding "validation" methods). The "detail" method could return the additional detail for the specialisations.
Don't know if that helps answer your question though.
Regards,
Gary Menzel
On 10/26/05, Dawson, Michael <[EMAIL PROTECTED]> wrote:
In our environment, we have user information scattered here and there. For example, we have many different user databases/directories such as:1. Active Directory (Accessed by both LDAP and VB COM)2. AS400 Student Information System3. Datatel Colleague Student Information System4. Shelfware Applications5. Home-built ApplicationsFor discussion purposes, in all of these systems, we have basic, "shared" user information such as:1. First Name2. Last Name3. Username/userid4. (A few other attributes)I would like to have a common "User" object (cfc) that encompasses most, if not all, of these systems. However, as you can guess, there are many attributes that are not shared between systems. For example, email address is not available, or even stored, in a couple of our systems.Now, down the the basics. A user is a user. Right? Or is it more-correct to say an Active Directory User is an Active Directory User, but a AS400 User is an AS400 User. This is where I am getting confused. (I understand the concept of not modeling an object that only mirrors the persistence layer.)Does it make sense for a single User object to cover all of the bases, or should I have separate objects for each type of user: ADUser.cfc, AS400User.cfc, ColleageUser.cfc? The gist is that some attributes are shared between users in different systems, but not all are.Then, part two of my question: What logic will let me transfer, and validate, user information between the various systems? Let's say I need to create an Active Directory domain account based off of AS400 student information.Do I need some sort of handler/manager that will pull only the necessary AS400 user attributes and create an Active Directory user object? What about the "holes" where the AS400 cannot completely fill the ADUser.cfc object? How will I get my ADUser object to validate correctly?Now that I have a ADUser object, semi-created from the AS400User object, how do I validate that "some" of the information is OK only because I know it came from an already-validated system (AS400). In addition, I don't want to lose the normal validation that I would perform on a ADUser object.To sum it up with my final thoughts, for now.1. Should one object serve multiple, but related, purposes?2. If an object can serve multiple purposes, how do you validate per-purpose?3. Is this a good candidate for inheritance or composition? An ADUser is-a User; An AS400User is-a User. I don't think composition fits this problem.Thanks for any suggestions with this.M!chael A DawsonDatabase Administrator and Manager of Web ApplicationsOffice of Technology ServicesUniversity of Evansville1800 Lincoln AvenueEvansville, IN 47722812-488-2581MSN Messenger ID: [EMAIL PROTECTED]"There are 10 types of people in the world: Those who understand binary numbers and those who don't."----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone ( www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
