[MUD-Dev] Object and class heirarchies -- are they really necessary?

[J C Lawrence]

I recently went over to chat with the Skotos gang.  One of the
things that came up was the handling of object heirarchies.

Most of the OO-ish MUD designs out there have well developed class
hairarchies with (often) dozens of classes related in variously
complex fashions by a rather detailed inheritance tree with
individual objects being descendents of some highly refined (in
inheritance terms) branch of the tree.  Its a well known and
excercised approach with a lot of prior art and well known problems
(eg trying to fit a new class into such a tree that attempts to
assemble features of widely seperated branches can be a bitch).

The Skotos guys (mostly Christopher Allen) made the point that at
Skotos they instead essentially have only one object type, and
everything is then an instance of that type.  Thus player
characters, NPCs, swords, rooms, bricks, pebbles, trees, sacks, etc
etc etc are actually all instances of the same super-class with the
only actual variance among them being in the values of the data
attributes of each object.  Thus, yes, it is trivial to walk inside
your sword, fly a banana, pick up a room and throw it in the bin,
etc and so forth.  The only actual differences are the internal data
values, and thus the _reactions_ of all the available methods.

This surprised me as I'd been tending in that direction myself
without ever having noticed.  My object trees have been getting
simpler and simpler, with less and less internal structure,
following this trend quite closely withuot ever noticing it.  Its
almost at the point now where the only reason for having a class
heirarchy is for logical clarity (so I don't have one huge class
definition with 3,000 methods).  I then assemble my very simple
class heirarchy from these easily omprehendable components into a
small number of super-classes, and then descend my objects from
there.

  ie My inheritance tree fans out into many small banrches, and then
the branches then collect back together again (multiple inheritance)
to produce the super classes.

Christopher commented that they do the same things (assembling their
super-class from more malleable single-purpose pieces) -- except
that they do it conciously and with intent aforethought.

Having noodled it for a few days now, several things become
alarmingly easier: All those problems of namespace conflicts and
layering in standard inheritance models largely fall out as the
developer of a base class knows from the very beginning what the
structure is that he's going to have to be able to play nicely with.
The various problems of picking how to assemble the inheritance tree
of some new special object that really isn't quite the same as
anything you have, also tends to fall out (tho not compleatly).
Logical consistency between widely diverse object types becomes
easier to maintain (but still possible to do wrong).  The bigger
gain there is that feature set changes become instantly infectious
across the entire object space in that when you add a feature
everything instantly gets _and_ groks it -- which also reveals one
of the more insidious problems:

Security -- most especially in free user programming models.

With standard inheritance models (be it the normal top-down or
aquisition based models), it is easy to control and mandate what
behaviours and methods an individual client object may have.  It may
be difficult to get exactly the ones you want, but what you do get
is very deterministic, easily defined and documented, and (somewhat)
easily controlled and constrained across future changes to the
inheritance tree.  This is mainly due to the fact that there is only
one method and entry point for editing groups of object definitions:
edit a direct parent.

The result is that the impact of changes is more constrained as root
classes are typically stable and unchanging (and easy to lock down
as being impossible to change without extreme access
qualifications).  However, in the everything-is-the-same approach,
all base classes are root classes in that all objects (at some
level) descend and inherit from everything.  Thus changing one,
seemingly innocuous base class (perhaps dealing with the decay of
wood products in marine environments) has the potential to affect
every object in the entire game (eg whether or now you can leap tall
buildings in a single bound).

When your entire inheritance tree (from an object's perspective) is
that you all descend from the same super-class -- how do you handle
multi-user security and access controls for editing the consituent
components of that super-class?

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev