Rod, thanks for the reply. I do have another question about the
inheritance of the classes.
First, we have no real hierarchy of user types. A student may be an
employee, a student may be a faculty, an employee may be only an
employee, etc.
I don't see how a single pattern could accomplish this. Here is a list
of all the permutations that are currently possible:
Employee-only
Faculty-only
Student-only
Employee - Faculty
Employee - Student
Employee - Faculty - Student
Faculty - Student
It would seem that I would have to "know" what the user's types are
before actually creating the instance. Then, I would be able to choose
the correct class type such as "CreateObject("component", "EmpFacStu")
or "FacStu", etc.
Am I missing something?
Thanks
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Rod Buchan
Sent: Tuesday, July 29, 2003 4:34 AM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Suggestions for Academic-Type Users
Here's a suggestion, I haven't tailored it to your needs exactly (sorry
about that). It's written in pseudo-code so it's easy to read.
Feel free to shoot this down, I'm looking for flaws.
class User
----------
string name
string address
string username
string password
struct userTypes //This contains a structure of different user types for
this user
//Method to check if user is of a particular type
boolean isUserType(_typeName){
if (userTypes.keyExists(_typeName))
return true
else
return false;
}
//Method that returns a reference to the userType
UserType getUserType(_typeName){
return userTypes._typeName
}
//Add user type to structure
boolean addUserType(_type){
typeName = _type.typeName
userTypes.typeName = _type
}
class UserType
--------------
string typeName //super class
class Student extends UserType
------------------------------
//student properties and methods
class Staff extends UserType
------------------------------
//common properties and methods for Faculty and Teaching Assistants
class Faculty extends Staff
class TeachingAssistant extends Staff
class Employee extends UserType
etc
Obviously this all needs to be fleshed out - you may prefer a to use a
list or array to hold the userTypes. The main point being that you have
a single user with one or more extra types. Since the extra types are
all of type "UserType", you can keep adding more and more types without
breaking/modifying the user class. Plus you can modify any of the
UserType subclasses as much as you like. Seems like pretty decent code
separation, plus it's a good basis for future enhancements.
Not sure if it meets your needs.
Cheers,
Rod
----------------------------------------------------------
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).