Re: [T] Clean Object Class Design -- What is it?

"Topmind" <topmind_at_technologist.com> wrote in message
> >
> >
> > Now, one area I wanted to use an OODBMS and couldn't was in combat
> > simulation. Here we have classic inheritance taking place. As an
 example,
> > there are numerous kind of entities in the system interacting with each
> > other. It's convenient to break these entities down into subclasses
 such as
> > "combat" and "non-combat." Combat entities clearly have a different set
 of
> > characteristics from non-combat entities, but both are capable of
> > interacting with each other in the system. Within combat entities, you
 find
> > Air, Land, and Sea (plus some mixed units I won't detail here). I'm
 sure
> > you begin to get the picture. A decent theater-level simulation will
 have
> > 5,000 - 10,000 of these entities running about. Additionally, each
 entity
> > has missions assigned to them, which in turn have their own hierarchy
 (for
> > example, air missions can be offensive counterair, defensive counterair,
> > strike, escort, suppression of enemy air defense, etc.). Lots of
> > opportunity to use inheritance.
>
>
> A lot of these might be orthogonal features. How do you manage
> multiple independant taxonomies? Multiple inheritance? How do
> you prevent method name overlaps, etc.?
>

Orthogonal to what? By definition, I'd say any child class attributes not contained in the parent are orthogonal to other child class attributes. But by definition there is a common subset of attributes (location, name, etc.).

As for multiple independent taxonomies ... separate roots (or named objects, depending on the system you are using). In this case you could have multiple _dependent_ taxonomies (since an entity can have a mission), but an OODBMS can represent that kind of connected graph quite easily, so no worries there.

Multiple inheritance ... never had a problem designing it out. In the worst case, I would accept having redundant attributes in two different child classes. As for method name overlaps: 1) I design out mixins, 2) since we're dealing with data, methods aren't really an issue. Received on Sun Jul 08 2001 - 21:54:32 CEST