Gerhard,
Sorry. I should have said "inclusive" instead of "non-exclusive". Just for
the record, some terms exist even though they may have been removed from the
current, popular methodologies and languages.
Prior to design, when you aren't constrained by a particular language
(modeling or programming) or the particular tools employed, the most natural
way to represent this is to use inclusive subclasses.
A
/ \ {inclusive}
B C
This is typically represented using multiple inheritance when the modeling
language doesn't support inclusive subclassing. However, this is only due
to the introduction of constraints in the modeling language.
A
/ \
B C
\ /
D
However, as you said, Java does not support multiple inheritance (a
constraint introduced by the language) so we can't do that.
Again, in our case, all of the classes are concrete classes. Using your
suggestion, we could add to your model a Person class that implements
I_Person that also has an optional reference to a User instance and an
optional reference to a Driver instance. Is that how you would have done
it? Does this introduce any problems for OJB?
Later.
Mitch
-----Original Message-----
From: Gerhard Grosse [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 9:50 AM
To: [EMAIL PROTECTED]
Subject: Re: Inheritance mapping, storing new object associated with
pre-e xistingsuper object
On Tue, 21 Oct 2003 08:55:02 -0500, Mitch Norby
<[EMAIL PROTECTED]> wrote:
Hi Mitch,
How would you model this in Java? Wouldn't you just have two objects,
one of type User and another of type Driver, which happen to have
identical Person attributes? If you wanted to change a Person
attribute on your User instance, you'd have to do the same on the
Driver instance to keep those two in sync. Java has no built in
support for this scenario, no matter how you call it. (Hmmh, does the
term non-exclusive subclassing really exist?)
IMO the most natural approach to model this situation is using
something like the GOF Decorator pattern, where basically User and
Driver implement an I_Person interface and can share a reference to a
Person instance, to which they delegate all calls of I_Person methods.
This is easily mapped in OJB as a 1->1 reference from User to Person
and Driver to Person.
Cheers,
Gerhard
>We have the same issue. In our case, the classes are Person, User, and
>Driver. All of these are concrete classes. However, this has nothing to do
>with multiple inheritance. The subclasses do not inherit from multiple
>superclasses. This is a case of non-exclusive subclassing.
>
>As an example, a Person can be simply a Person or a User or a Driver or a
>User who is also a Driver.
>
>Due to (our understanding of) limitations in OJB we decided to create a 1:1
>relationship from Person to DriverInformation in order to handle this
>circumstance.
>
>If we have misunderstood OJB, please let me know.
>
>Later.
>Mitch
>
>-----Original Message-----
>From: Gerhard Grosse [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, October 21, 2003 6:55 AM
>To: [EMAIL PROTECTED]
>Subject: Re: Inheritance mapping, storing new object associated with
>pre-existingsuper object
>
>
>Hi Matt,
>
>Excuse me to jump in here, but I believe what you have in mind is not
>possible in Java and even less with OJB. If your B1 and B2 instance
>should 'contain' the same A instance as base class, they are identical
>objects, which would require a language that supports multiple
>inheritance (and virtual base classes). You could do that in in C++
>but not in Java.
>
>What you can do in Java (and OJB) is declare an interface I_A
>implemented by A, B1 and B2. I_A just declares all public methods of A
>and in B1 and B2 you implement this interface by delegation. That is
>in B1 and B2 you have a reference to a A object and all I_A methods on
>B1 and B2 are just routed to this reference. That way distinct
>instances of B1 and B2 can easily share a common A reference.
>
>HTH,
>Gerhard
>
>On Tue, 21 Oct 2003 00:27:02 -0400, Matt Mastrangelo
><[EMAIL PROTECTED]> wrote:
>
>>Chris,
>>
>>Just to clarify -- are you saying it's not possible to create the User
>>instance without also creating a new Person instance? Maybe my example
>>was not too clear. Let me re-explain:
>>
>>I have a base class A with two subclasses, B1 and B2. I have already
>>created an instance of B1 and stored it to the database, which means
>>that an A record and a B1 record were inserted. I now want to create an
>>instance of B2 that extends from the same A record as B1. Is this
>possible?
>>
>>Thanks again.
>>
>>Matt
>>
>>[EMAIL PROTECTED] wrote:
>>
>>>Matt,
>>>
>>>I believe since the Person and Student object exist it will set there
>>>values to null except the personId. Because in the User instance you are
>>>storing allthe other fields are null (if you set them to null when you
>>>declare them) except the loginName. So, ojb will know that person and
>>>student 001 exist and will do and update instead of an insert.
>>>
>>>You should create them on the first store. Or do not have user extend
>>>Student, instead have a 1:1 relationship. Depends on your requirments i
>>>guess.
>>>
>>>-chris worley
>>>
>>>
>>>
>>>>I'm trying to figure out how to store a new persisted object that
>>>>extends a pre-existing object.
>>>>
>>>>For example, I have 3 classes: Person, Student, and User. Student and
>>>>User extend Person. A Student object already exists, and I now want to
>>>>create a User object that inherits from the same Person as the Student
>>>>object. Is this possible? Here's a code example:
>>>>
>>>>User user = new User();
>>>>user.setLoginName("matt");
>>>>user.setPersonOid("001"); // A pre-existing person
>>>>
>>>>broker.beginTransaction();
>>>>broker.store(user);
>>>>broker.commitTransaction();
>>>>
>>>>The result of the above code is a NEW empty person object being created
>>>>with a newly generated OID (via a sequence). How can I associate the
>>>>new User with a pre-existing Person?
>>>>
>>>>Thanks again.
>>>>
>>>>Matt
----------------------------------
The information contained in this e-mail message is intended only for the
personal and confidential use of the recipient(s) named above. If the reader
of this message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that you
have received this communication in error and that any review,
dissemination, distribution, or copying of this message is strictly
prohibited. If you have received this communication in error, please notify
us immediately by e-mail, and delete the original message.
