Re: Changing Object Type in OODB

Hi,

I am surely not an OOAD guru, so I am only throwing my twopence in again and hoping for some comments from others with some more theoretical OOAD background.

Bob Badour wrote:

> 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?

Coad's check list mainly is derived from the simplest OO semantics and, yes, as already mentioned, a 'cookbook approach'. Fowler provides a collection of patterns which are by definition derived from everyday experience - they are not invented but discovered, thus, yes, 'vaguely heuristic', if you like so.

Compared to the process of relational modelling as far as I know it (explore functional dependencies, create ER model, normalize) I do personally think your claim might be fair up to some point. I don't know of an OOAD modelling approach that is even closely as 'mathematical' as the relational one.

However, I don't know how dynamic behavior would be handled in relational modelling and I have only looked into a small subset of OOAD approaches.

> 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.

Yes. Manager inherits from Employee, maybe with a common Role interface.

> 2. The Person object class defines some method or property for identifying
> its associated roles.

Probably.

> 3. The associated role object instances have some method or property that
> refers back to the Person object instance assuming the role.

Yes.

> 4. A Person object instance can assume multiple Employee roles and/or
> multiple Manager roles.

Not necessarily, but possibly.  

> 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?

That depends on the requirements, but probably yes. But I wouldn't describe this model in an OODBMS but as an OO model, would put it into code and then expect an OODBMS to simply make it persistent. Perhaps splicing hairs now...

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

In other environments you may have the implicit notion of the extent of a class, but in Java as a language you don't. (I think that JDO supports this concept, but I may be wrong.)

> 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?

Yes. Though I think the latter would be the most uncommon. There also might only be a global collection of Employees and a filtering method that produces only the subset of Managers or no global collections at all but a visitor collecting Employees from the department hierarchy or...

I am not quite sure what you would like to show here. If your point is that OOAD modelling methods are not as mathematically concise as relational modelling and (among other differences) therefore may yield more possible resulting models, well, congratulations, you've won, erm, whatever... At least as far as I'm concerned.

My point simply was that the example you presented IMO doesn't work for most imaginable domains where you can expect to find persons, employees and managers. I don't expect my objects to change their type in-memory at runtime, I don't expect them to do so in the database. To cope with such behavior I like to view this as one object playing different roles. And I still don't see why it should make a difference if I want to make my objects persistent or not.

> 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?

Why should you want to do that?

> 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!

As you like.

Regards,
Patrick Received on Sun Jul 22 2001 - 01:29:33 CEST