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

>
> "Topmind" <topmind_at_technologist.com> wrote in message
> > >
> > > My primary domain is military applications. Areas I've worked in range
 from
> > > command and control systems (which resemble commercial enterprise data
> > > systems), intrusion detection, combat simulations, embedded controllers,
> > > radar surveillance (embedded apps), to VLDB systems involving the
 retrieval
> > > of intel data.
> > >
> >
> >
> > Interesting. I suppose you could not share specifics about what
> > the subclasses you intend to use? I am not much of a fan of
> > OO with business applications. Those that try to persuade me that OO is
> > great usually fall into two camps:
> >
> > 1. One doesn't really need to use subclassing
> > to get benefits from OO.
> >
> > 2. Subclassing (and polymorphing off those subclasses)
> > is quite useful in biz apps, but Topmind just cannot
> > recognize them.
> >
> > If it's #1, then how does OO improve it? If it's #2,
> > then please list decent, stable biz taxonomies
> > in outline form that non-me's have discovered.
> >
>
> As I've mentioned before (maybe it wasn't this thread), I'm not in favor of
> using OODBMSs in "biz" (by that I assume you mean enterprise data stores ...
> diverse apps hitting central data) applications. The command and control
> system I put in place used an RDBMS, and I wouldn't even consider for a
> moment replacing it with an OO-type system.
>
> 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.?

>
> >
> > > Currently I've moved an abstraction level above databases,
> >
> > Rather than fiddle with yet another layer, I try to
> > "surf" the database features and take advantage of it's
> > inherit power.
> >
>
> Let me be a bit more clear about what I mean, my current work involves
> retrieving information from structured and un-structured sources. This
> means I not only have to deal with databases, but I have to deal with
> documents (both unstructured and structured in various forms) ... all in the
> same "query." That means working at a higher abstraction level. It's
> interesting.
>

Oracle has a "document query language" extension to SQL, but it aint cheap.

-T- Received on Sun Jul 08 2001 - 19:42:03 CEST