On Jul 2, 2006, at 8:55 PM, Ian Joyner wrote: On 03/07/2006, at 7:27 AM, Mr. G Brown wrote:
Yes, A VerifiedPatient would be a subclass of a PatientAlias (from a Java perspective); they would have many properties in common, methods, validations, etc. A VerifiedPatient would link (from a SQL perspective) to many PatientAliases, and under each PatientAlias there would then be links to information entered under that alias.
But from what I have read, there are bugs with inheritance, and it might be better to just duplicate the common properties and methods.....
No, all three WO implementations of inheritance work fine, so that should not put you off. You might run into things that seem like bugs if you misuse inheritance...
That's good..
On Jul 2, 2006, at 4:39 PM, Ken Anderson wrote:
Mr G. Brown,
I think it would be necessary to understand your object model a little more before being able to recommend if/how to use inheritance. At the moment, I really don't see any entities you have that are good candidates for inheritance, unless I'm misunderstanding your problem. It seems to me like you need a Patient entity and a PatientAlias entity, related Patient <->> PatientAlias.
Yes, but from a Jave perspective the Patient is a subclass of PatientAlias, or should be...
Can you please give us some more detail?
Well the above is the gist of it...
Consider Mary Smith, who has some tests, then next year is Mary Doe, and gets more tests, then the next year is Mary Smith again, who gets more tests, then the following year is Mary Rogers. Now find all the info for Mary Smith/Doe/Smith/Rogers. And yes, an ID number would work...in an ideal world where there weren't any typos or mistakes with that property.
OK, you are describing a 'has-a' relationship, not an 'is-a' relationship.
a VerifiedPatient 'is a' PatientAlias , (a special alias, which is why I asked about inheritance), AND 'has a' to many relationship with objects of its parent class (PatientAliases). Of course it will work to have a VerifiedPatient table and a PatientAlias table and cut and paste common code, properties, etc. between the classes, but that's not very DRY (don't repeat yourself) and OO, but it may have to do. Inheritance models the is-a relationship.
Yes, a VerifiedPatient 'is a' PatientAlias ,( a special alias) From what I read, each single person potentially has multiple identities.
Don't we all? OO modelling won't solve this problem, since it might take some detective work to find that the patient presenting herself as Mary Smith this year was Mary Doe last year. For this you might want a previous records relationship, which you can link, once you have found this to be the case.
That's why the PatientAliases are linked to a VerifiedPatient. Or you might want to just resolve multiple records into a single record, but that all depends on the policy of the hospital, which it sounds like is the first.
The inheritance relationship would be used more for modelling common attributes of PATIENT, DOCTOR, NURSE, STAFF_MEMBER as inheriting from PERSON, or even better, DOCTOR and NURSE would inherit from STAFF_MEMBER. Thus you have divided STAFF_MEMBER into categories or subclasses depending on their role in the hospital.
Now it would be nice to extend a PatientAlias class to a VerifiedPatient class, BUT with the "to many" and "to one" relationships will that work?
Probably not.
or will that cause problems?
Probably.
Does EOgenerator work with inheritance?
Yes very well.
And what flavor of inheritance would work best here?
Most likely none.
Sounds like you need a good book to explain the ins and outs of OO. Try Bertrand Meyer's very clear "Object-Oriented Software Construction":
I know I can get it to work if
Well thanks for your insights.
My pleasure Ian
|