[MUD-Dev] SMAUG Code (was Personality Types)
justice at softhome.net
Thu Aug 23 03:33:02 New Zealand Standard Time 2001
From: "Alistair Milne" <krug at krug.org.uk>
>> From: Kwon Ekstrom
>> I've never worked with Cold so I don't know how their object
>> heirarchy is, but OOP is meant to save time, code, and allow
>> better understanding by associating method calls with the data
>> structure they work with. I'll admin I've seen several different
>> OO muds with a terrible object heirarchy, but with OOP planning
>> (something mud development often lacks) is even more important.
> You're implying here that the best Object Oriented approach is to
> use the equivalent of Get() and Set() methods. In my experience,
> the better designed class is the one that has methods for the
> roles that the object will play, rather than simply direct access
You seem to have taken what I've said completely out of context.
What that statement means to me is to handle the work by the object
with the data, not the other side. Which is where you seem to be
going with this.
> functions to the data. For example when a player types 'look' in
> a room, rather than having methods in the Room class for
> GetLongDescription(), GetExits(), GetContainedThings(), etcetera,
Yes, that would be amazingly ugly, I actually use a display(Token
ch) method. With the level of abstraction that I'm using it'd be
impossible to get away with that level of detail. Yes, I do have
several methods setup to retrieve/set data as you mentioned.
Actually the Room class implements a whole heirarchy of methods from
interfaces to handle things like containing creatures.
In this case, display handles all the dirty work, etc... it takes
the data directly and outputs it. By simply using get/set methods,
you're just adding object overhead to a data structure without a
major gain, unless you have a variety of things to do in order to
modify those values. I use alot of get/set methods, but I have a
wide variety of other methods to handle specific tasks that are
related directly to the data.
-- Kwon Ekstrom
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev