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

[Lazarus]

Are they necessary?  I say yes.  Are the complex multiple-inheritance
models many propose necessary?  I think not..

On Tue, 21 Mar 2000, J C Lawrence wrote:

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

Been there, done that.  Thrown it away several times for exactly that
reason.  I do wish in addition to being 'well known and exercised' it were
also well documented so the rest of us did not have to learn the falicy of
the approach the hard way.

> 
> 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 is where I wound up.  My latest design concluded with a base class of
'mud_thing' from which everything else was derived.  I thought it was cute
to pick up my test character (could be used for trouble makers as well)
and put him in my pocket.

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

Welcome to the enlightened..  I thought I was one of the few who came to
the inevitable conclusion of this line of reasoning.  I gotta talk to
these Skotos folk since it seems they have got it right.

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

Not wanting to start a religious war, but no way to say it any other way,
it has been said that multiple inheritance is the crutch of a poorly
designed class structure..  about half way between 'goto' and 'void
casting'.  I think I have tried (and rejected) over a dozen different
class heirarchies on our diku hack and slash mud and have concluded the
same thing you are realizing.  Rooms, objects, characters ..  all of these
are 'mud_things'.  They may contain other mud_things.  They may be
contained within other mud_things.  They all have the same basic
properties.  They all have a large number of common attributed/methods.  
Things are never the same once you start to think of OLC as 'picking this
room up and carying it to somewhere else'.  The use of a master
'mud_thing' class also fits the KISS rule far better than any of the other
implementations I have seen.

The FAQ of this list says that interitance trees are a topic of this list
and I find it interesting that noone has presented in detail thier design.
I am glad you brought up a point that has bothered me for several years
with regards to why everyone seems to feel it necessary to make a dogs
breakfast of trees for what intuatively seems a very simple structure.

<snip a lot of good stuff>

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

What is your question?  You handle security of any instantiation the same
independant of whether it is multiply derived from multiple base classes
or derived from a single super class.  Or, are you proposing online
editing of the base class definition?  Now that would be one heck of a can
of worms.





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