Re: Changing Object Type in OODB

Hi,

Bob Badour wrote:  

> In another thread, a Java-only OODB proponent proposed the following as an
> obvious, straightforward design not requiring any thought:
>
> >class Person
> >class Employee extends Person
> >class Manager extends Employee

I wouldn't agree here. In Coad's 'Java Design' for example there's a (IMO quite sensible and well justified) 'when to inherit' check list. It includes:

1. 'is a special kind of', not 'is a role played by a'
2. Never needs to transmute to be an object in some other class

Obviously the above example fails on both points. Employee and Manager are roles that can be played by Person instances (or, more general, by Party instances), not special kinds of Person/Party and a Person may be promoted to a different position. This would be enough for me to not consider inheritance.

> 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'. ;)

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.

Just my two micropence,
Patrick Received on Sun Jul 22 2001 - 01:29:28 CEST