Hi Denver, Got your point, thank you very much...
I'll try to change my object model accordingly, see if it that fits. It may be possible that you saved my life :)) Do you have any ideas about how to fit the time dimension in the PersonRole class effectively? I mean, in a person's history, it's very likely to see such information: he's a patient of organization x from time a to b he's an employee of organization y from time c to d he's a doctor of organization x from time c to d . . those records all should keep role specific data as well for future reference (Like he's a "good" patient of organization x from time a to b, he's a "lazy" employee of organization y from time c to d, anyway you got the point :)) Definitely, I'll be asked about the status of the person or an organization at a specific time together with the related information. Like, give me the names and the lazyness degrees of all the employees of organization y as of time g. What is person A is doing now? Who were the "good" students of Harvard University in 1985? What do you suggest as a structure for fast and easy query capability? (Any ideas are welcome, the idea owners will win a dinner at an oriental restaurant in Istanbul, anytime they are able to visit...) Best wishes, Teoman "Denver Braughler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Teoman Haliloglu wrote: > > Depending on the person's role(s), you have to know different stuff whereas > > you have to take different actions to different events. > > Which means you'll need to keep different data and methods for different roles > > This is exactly the point. > Once a person has data stored under the Contractor class, it is not the case that there is necessarily a place for all of it in the Employee class. > > > in addition to default data and default methods. > Meaning those that pertain to any Person - yes, that is correct. > > > That would suggest keeping the roles as classes inherited from Person, am I wrong? > Yes. > > > Also, even Cache documentation has the same example everywhere, that was > > what encouraged me to go this way... > But it assumes that you will never try to change an object's type. > "Once an Employee, always an Employee." > > If a Person can be an Employee and a Patient, then Employee and Patient need to have a pointer to the Person instance, not be subclassed from it. > > That may not sound right. > But in this model, the Person is the object. > Employee and Patient are just various Roles that instance of Person can have. > > You could have an abstract class PersonRole that has pPersonID as Person and pRoleID as Role. > Then Employee, Subcontractor, Volunteer, Patient, etc., could extend PersonRole. > Each of those classes would contain the specific methods, properties, etc., that pertain to that subclass. > > > Because I only need employee specific data when he's my employee, when he > > changes his role and goes back to being an ordinary person, I wouldn't care > > about losing data. > That depends. I can tell you that in the USA that would not be acceptable... > nor for a Person who was a Patient or Customer. > > > (I do keep employment history data by the way) > Well, where? > Apparently not in Employee, so what is in Employee that isn't in Person? > The answer is that you store all that employment history somewhere else, why not in Employee and just have Employee point to Person? > > > If he becomes my employee again, I will enter the specific data again > > and save him as an employee. > But what if he is a Volunteer or Patient simultaneously? > What if he becomes a member of the SteeringCommittee or a Stockholder? > > > I think I can play with globals and subscripts for switching classes, but > > looking for a better, object oriented way... > At the level of abstraction you are describing, an Employee is *not* an object, but rather a temporary relationship between a permanent Person and your company. > > > Still, if you think switching objects between classes in time is not good > > practice, what would you suggest? > As I said before: > > > Your situation suggests [to me] that you need Person and Role. > So I suggest Person with Employee pointing to an instance of Person.
