[MUD-Dev] [DGN] [NEWBIE] Suggestions on (OO) Server Design.

[Kwon Ekstrom]

From: "Greg Munt" <greg.munt at btinternet.com>
> From: Kwon Ekstrom <justice at softhome.net>
>> From: "Pure Krome" <muddev at world-domination.com.au>

>> My mud is written in java, and uses a form of this, Java allows
>> multiple inheritance in the form on interfaces.  I have a Token
>> interface which defines things necessary for all mud objects,
>> Mobs (Creatures in my system) and Items (Objects, the keyword is
>> reserved and Item is more descriptive imo).

> Object isn't a keyword, and isn't reserved. Having a type named
> (for example) com.slimy.devmud.Object is quite legal. I'm not sure
> how Item is more descriptive than Object. I'd use something like
> WorldObject, and I find the name Token to be misleading - it makes
> me think of string tokenisers and compiler compilers. Having said
> that though, the actual names given to classes is so trivial that
> it makes very strong opinions on the subject quite religious.

True, object isn't reserved, since each package maintains it's own
namespace, but because java.lang.Object is used quite a bit in the
standard packages (and is very handy as a generic storage mechanism)
I think it'd be more trouble than it's worth to use that as a
keyword.  For all intents and purposes in my mind it's reserved.

As for Token, Token represents an object that can reside in the
world.  Token thru a variety of interfaces, define methods to handle
pooling, referencing, permissions, locations, and connections.

Item and Object are about as descriptive actually, I prefer Item for
a variety of reasons, it's a third shorter to type!  Actually I find
it more descriptive, but I can't put my finger on exactly why.

>> I have an abstractToken which provides a default implementation
>> of Token, which is extended by Room and NamedToken, NamedToken
>> provides methods and fields to handle an object with names (as
>> the name implies).  Creature (Mobiles) and Item (Objects) extend
>> NamedToken.

> Why is Room not a NamedToken? Do your rooms not have names?

Rooms have a short description, but you don't reference rooms by
their name.  The hasName interface which NamedToken defines a
default implementation of is designed to allow reference via name.

>> Java only supports single inheritance, with multiple
>> interfaces...  By the time they get to NamedToken there's about a
>> dozen interfraces that get inherited.

> A dozen? That sounds rather large to me. Would you care to talk
> about the interfaces implemented by NamedToken?

NamedToken only implements hasName and Token, Token itself uses
several interfaces to handle things.

I tend to write interfaces to handle a specific task that will
likely be used repeatedly, then write a default implementation.
This allows me to write fairly generic code that doesn't care what
kind of object you are.

There are several places where this approach has saved me alot of
code.  For example to handle containing items, instead of:

  if (ch instanceof Item) {
    -- Item specific handling
  }

  if (ch instanceof Room) {
    -- Room specific handling)
  }

  if (ch instanceof Creature) {
    -- Creature specific handling
  }

I use something like:

  if (ch instanceof Container) {
    Container tch = (Container)ch;
    <specific handling>
  }

The only problem with this example is that Item doesn't implement
Container, Item doesn't do much but uses subclasses of ItemType to
handle each specific task.

-- Kwon Ekstrom

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