Teoman Guess we are back with the many-many relationship
here goes for the dinner in Instanbul...... Class Person Property pName Relationship rConnections as Connection [ Cardinality = parent, Inverse = rPerson]; Class Organisation Relationship rConnections as Connection[ Cardinality = many, Inverse = rConnections]; Class Connection Relationship rPerson As Person[ Cardinality = parent, Inverse = rConnections]; Relationship rOrgansiation As Organisation [ Cardinality = one, Inverse = rConnections]; Notes I have made the Connection a child class of person - if a person is deleted all the connections are deleted - this probably makes sense in most cases, but you may want to make it a stand alone class Also with this structure there is the possibility for many links between one person and one organisation Now to make a Doctor/Student/Employee type classes I would sub class this off the class Connection here it would inherit the linkages but be able to introduce Doctor/Student/Employee specific properties eg Class ConnectionDoctor extends Connection property ..... You could add properties to the connection class like property pStartDate property pEndDate property pCurrent [calculated] that would then be inherited by all Doctor/Student/Employee sub classes You may want to sub class the Organisations into specialisations School/Hospital/College etc but probably not sub class the Person How does this look for the dinner !!!????!!! Peter On Fri, 21 May 2004 18:23:47 +0300, "Teoman Haliloglu" <[EMAIL PROTECTED]> wrote: >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. >
