Interfaces and Behaviors - WheelMUD - A C# MUD Server - Forums - WheelMUD

Forums

Unanswered Active Topics

Forums Search Members

Forums > WheelMUD > Design

Interfaces and Behaviors

Last Post 21 Dec 2009 05:18 PM byFastalanasa. 10 Replies.

Sort:

	Prev Next
You are not authorized to post a reply.

Author

Messages

pglaspey

New Member

Posts:38

14 Dec 2009 03:51 AM
As I have been exploring the codebase I came across some situations where we have an interface (IContainer) and we have a behavior (ContainerItemBehavior) And they both seem to serve the same purpose (to decorate a container with propeties). Can someone explain why we need both or actually the concept driving both of these. I did not see that all behaviors have a corresponding interface...

Karak

Locutus of WheelMUD

Basic Member

Posts:320

14 Dec 2009 07:14 AM
I think mainly the IInterfaces are legacy and we're trying to remove/replace them with more appropriate ways to expand/define functionality. When one wants to know if an Item is a Container, they can ask the Item's BehaviorManager if it has a ContainerItemBehavior. This is more flexible since, for instance, one suddenly decides they want an item that is both a portal and a container for some reason, they can do that without adding a ridiculous PortalContainer.cs just for their one specially designed item.

pglaspey

New Member

Posts:38

14 Dec 2009 07:36 AM
That is good to hear.

Ben

The Uncanny Gecko

New Member

Posts:88

14 Dec 2009 06:24 PM
I am currently working on Containers for the Empty and Fill commands so I will look at how the older interfaces can be refactored out.

Ben

The Uncanny Gecko

New Member

Posts:88

16 Dec 2009 06:03 AM
So before I go about a refactoring I want to summarize what would change if we do away with some of the specific Item Instance classes. First of all the Item class needs to not be abstract anymore. Then these classes are killed off and their specific properties are accessed through the BehavioManager. AbstractContainer, Consumable, Container, Currency, Furniture, Liquid, Listening Device, Portal, Potion, Stackable Item (currently abstract), The following classes are more specialized and remain (and they don't inherit from Item) Door, DoorSide, Exit, ExitEnd So the core system only will have a basic item object. There would still be an IItem interface, and extensions to the system could add additional implementations of behaviors, and items if required. I agree with Karak, that this is a good direction, but want to have consensus agreement before making this fairly large change in code. Thanks, Bengecko

Fastalanasa User is Offline

Grumpy Half-Elf

Advanced Member

Posts:555

16 Dec 2009 06:29 AM
I subscribe to Occam's Razor, keep things simple. I like the direction we are heading with this. Could you do a quick write up between the behavior managers and properties, and how they relate/call the database tables? I'm already way behind the curve here, and would like so see a wiki entry about this.

Karak

Locutus of WheelMUD

Basic Member

Posts:320

16 Dec 2009 08:04 AM
(All from memory here, don't have code available at this PC yet...) As is, Items should be saving their list of Behaviors upon saving, whether they are an Item or a class that derives from Item. As is, if a Portal is saved to DB, it would be loaded as an Item class which is given the PortalBehavior. This would not change. The intent of having something like a Portal class itself is to make it easier to create such things the fly, IE for a Portal-creating spell. The code can look something like: Portal newPortal = new Portal(); newPortal.Exit = 123; currentRoom.Add(newPortal); Instead of: PortalBehavior portalBehavior = new PortalBehavior(); portalBehavior.Exit = 123; Item newPortalItem = new Item(); newPortalItem.BehaviorManager.Add(portalBehavior); currentRoom.Add(newPortalItem); This could be slightly simplified with constructors that take (a collection of) Behaviors and the application of construction syntax like: Item newPortalItem = new Item( new PortalBehavior() { Exit = 123; } ); currentRoom.Add(newPortalItem); Personally, I like the last form well enough to warrant removal of the shallow classes.

Karak

Locutus of WheelMUD

Basic Member

Posts:320

16 Dec 2009 08:28 AM
Sorry for my terrible formatting. It seems our advanced editor has gone away and I've never bothered to learn much HTML.

Ben

The Uncanny Gecko

New Member

Posts:88

16 Dec 2009 08:40 PM
Creating Item Instances I think that Karak's final example is pretty close to the basic usage that would be required. For a single behavior a constructor would be available for Item(IItemBehavior itemBehavior) For multiple behaviors we might have Item(IList itemBehaviors) These would really only be used by code that builds the world. The rest of the time the following constructor would be used Item(IItemRecord itemRecord) Then the child behaviors would be automatically be loaded. I need to add the ability to save in the database a non WheelMud Item Behavior by adding a column with the class name to use to construct the extended behavior. This is similar to the functionality that the Items currently have. Getting Behaviors from Item Instances To get a behavior record from the Item I was thinking of adding a generic method. Something like item.getBehavior < ILiquidBehavior >(); I figure that this will work for both internal behaviors and externally supplied behaviors since the external command that is using this new behavior will know about it and be able to ask for it. The internal commands will know about the internally supported behaviors.

Ben

The Uncanny Gecko

New Member

Posts:88

17 Dec 2009 05:12 AM
I have added the start of an overview of the proposed handling of items at www.wheelmud.net/Wiki/tabid/56/Default.aspx It is a merger of existing and proposed technology.

Fastalanasa User is Offline

Grumpy Half-Elf

Advanced Member

Posts:555

21 Dec 2009 05:18 PM
Thanks!

You are not authorized to post a reply.

Forums > WheelMUD > Design

Active Forums 4.1

Creating Item Instances

Getting Behaviors from Item Instances