Re: Changing Object Type in OODB

>> How does an existing object of type Employee change its type to Manager
 in
>> the OODB or in Java?
>>
>> Presumably, when I hire someone in a non-management position, I create an
>> Employee object instance that is not a Manager object instance, and I
 give
>> the new Employee object a specific identity.
>>
>> If I later promote the person into a management position, I need to
 change
>> the type of the Employee object instance into one that is also a Manager
>> object instance, and I have to do so without changing the object
 instance's
>> identity.
>>
>> How is this done in Java?
>
>By a different design that doesn't hard-wire a person instance to
>its role by using composition and interfaces rather than
>inheritance. There are some approaches given in the said book,
>also some of the patterns described in Fowler's 'Analysis
>Patterns' (esp. those on accountability) might be of interest. Of
>course the definitive answer to the question is: 'It depends'. ;)

Of course, I realise that one must know the full set of requirements before one can intelligently engage in detailed design. Still, I find some utility in comparing relational modelling methods with object modelling methods.

You mention Coad's "Checklist" and Fowler's "Patterns". Would it be fair to say that the OO modelling method relies on vague heuristics and a cookbook approach? Do either Coad or Fowler articulate any underlying principles by which to derive their lists or to recognize candidates for inclusion in their lists?

You proposed modelling Employee and Manager as roles of Person object instances for one possible design, and I would like to explore that design a little further. (Ignoring your Party object class for simplicity.)

I assume:

1. The Employee and Manager roles are modelled as two additional object classes whose instances have identity separate from the object assuming the role.
2. The Person object class defines some method or property for identifying its associated roles.
3. The associated role object instances have some method or property that refers back to the Person object instance assuming the role.
4. A Person object instance can assume multiple Employee roles and/or multiple Manager roles.

Are these reasonable assumptions?

When it comes to describing this model in an OODBMS, am I correct in identifying the following additional criteria that designers might ask themselves:

Will users need to identify the set of all Employees? Will users need to identify the set of all Managers?

Or do we further assume that all object classes define an implicit collection of all their instances?

In other words, could the role-based design have further flavours with and without independent collections of Employees and Managers? One design would have a single global collection of Persons who might or might not assume Employee or Manager roles, and another design would have global collections of Persons, Employees and Managers?

Does Coad, Fowler or anyone else provide any guidelines regarding duplicating data in the Employee or Manager role object instances that already exists in the Person object instances? Height or hair colour, for example?

>I have set a followup to c.l.j.p. only because I don't think this
>is closely related to the theory of databases.

I think that an exploration of the principles and methods by which one models data in an OODBMS relates to the theory of databases. I undid the followup -- thanks for the heads up!

Best Regards,
Bob Received on Sun Jul 22 2001 - 01:29:31 CEST