Hi, Seems that it will work for me, although in my case a person is not allowed to have two roles at a specific time, as all the role types are in fact different employment times, and a person cannot be employed at two organizations at the same time. So I'll simply add a constraint that a person have only one active role.
Do you think it is a wise idea to implement two base structures, simple many to many and time-framed many-to-many for future use? (ManytoManyLeg, ManyToManyCross, TimedManyToMany classes with all utility functions and base queries etc.). Then to simply inherit those classes accordingly for other many to many implementations? Or is it better to go case by case? Anyway, actually the dinner is there for everyone in the group (I beleive you won't refer me to all your friends visiting Istanbul, that will result in bankrupcy!) , but the extra dessert goes to Peter :)) Best wishes and many thanks, Teoman "Teoman Haliloglu" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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. > >
