Interfaces and DI

[DavidRieman]

We used to have a ton of interfaces. We'd have things like IWeapon and then a concrete Weapon class that matched exactly. We realized this didn't really do anything for us as the concrete classes were not heavy, so cases where you'd want DI for angles like testing didn't have any real wins. What it did do was make it harder to try to mold the framework to newer, better techniques like the Behaviors system (more on Behaviors here), not only due to having to double a lot of changes, but due to extra indirection in seeing what all was being used and where. So those myriad of interfaces that felt redundant are long gone. (For example, if we want to model a Thing to be a weapon, we actually want to compose it with something like a WeaponBehavior instead.)

Ideally the places we most want to use interfaces are to describe generic systems where we don't have to know the full details about those systems (like ISubSystem or ITelnetOption) to work with them.

In the past, we'd also had various discussions about interfaces on our way through this journey so far. I'll post the more interesting/useful bits here.

This thread contains restored content from prior forums; see #134 for details.

---

[May 2009]

So we had this idea that Behaviors would be the things that could be used to extend items' abilities. Let's say you have a stick, but then you add the WeaponBehavior (and appropriate weapon properties within that behavior), then code like the 'wield' command would allow you to wield any item that has the WeaponBehavior, etc. Is there any reason we don't ditch the whole interface thing for Items altogether, and give them, say for a barrel you can put items and liquids in, a LiquidContainerBehavior and ItemsContainerBehavior?

Alternatively there could be a property on a ContainerBehavior which states what types of things can be put in it: liquids and/or other items. The ContainerBehavior itself would house the list of contained items as one of its properties, and be responsible for handling persisting the list of contained items when it persists, and tell all its items to persist themselves, etc.

[ed. update 2021] Actually contents would likely be .Children of the container Thing.

I'm not sure if the "liquid" of a potion is considered an item right now. And we don't have a waterskin with the 'fill' command and room fountains or streams to fill it wilth, etc.

But anyway, the way I understand it as currently designed, a Sword, Shield, Helmet, Gauntlets, etc are just normal Items which have a WeaponBehavior, ShieldBehavior, or ArmorBehavior applied to them.

I feel that an Interface for these behaviors would be ideal.

I can see many instances where a loop would want to know all IDrinkable items...which is a trivial thing to check for (blah is IDrinkable).

Whereas, if we store behaviors in the item, that might be a Dictionary or a list that then has to be iterated through, as well.
Unless, you're considering that an item's behavior is just an enum, and the behavior code is elsewhere or something along those lines?

And yes, there should be a difference between ILiquidContainer and IItemsContainer, in my opinion. That's a core trait of a container, is it water-tight?

...I'm also surprised that you're not on the side of compile-time enforcement.
I guess my current question is, how will these behaviors be implemented?

Being able to iterate and detect all IDrinkable is great. That would be great for weapons and armor too. The trickiness comes in crossover items; do we need a new class for every conceivable combination?

What do you mean I'm not on the side of compile-time enforcement? (BTW I don't have all the answers here, I've actually not done interface-heavy programming before; the polymorphism I've done has generally been sufficient to use only the 'class inherits from class' variety and ignore interfacing altogether.)

I think along the strict Behaviors approach, that generally an Item wouldn't have more than a couple behaviors on average, so it would still be sufficiently performant. Iterating them would still be pretty fast, and since it only occurs when a player does a command or action that is relevant, like attempting to wield a target item, then there tend not to be a blanket 'iterate all behaviors of all items' operation very often. Exceptions might be things like 'find every burnable object on the player and check if we burn it up' or whatnot, but a player doesn't just type 'drink' and have it automatically scan for drinkable items to perform the operation on.

In C#, you cannot derive from more than one class, however, you can derive from an unlimited amount of Interfaces.

class Potion: IDrinkable, ILiquidContainer

At compile-time, if the potion class has not implemented the necessary IDrinkable methods and the ILiquidContainer methods you cannot compile.

More ideally, we would have:

class LiquidContainer: ILiquidContainer <- implements required interface methods

class Potion: LiquidContainer, IDrinkable

class Waterflask: LiquidContainer, IDrinkable

Not all liquid containers can be drunk out of, a latrine, for example. But, we're specifically making waterflask and potions drinkable.

The normal 'interface' method of coding is this...

• An Interface enforces a set of methods that all derived classes must implement. This allows you to typecast ALL derived classes as that interface.
• Then a baseclass, that inherits multiple interfaces, this baseclass implements all the required interfaces.
• Then another class that inherits the baseclass, assigning unique features to that either in code or via more interfaces.

So, a shield... it's wearable, can be wielded, provides armor, metallic, can be a weapon.

class BaseShield: IWieldable, IWearable, IArmor, IMetal, IWeapon <- implement the required methods... remember, an interface is only a list of methods that are required, no actual code is normally here.

All normal shields can be BaseShields, and they have all the same functionality... feed in its stats for the standard different ranges of normal shield behavior.

Then a designer wants to make a flying shield...
class FlyingShield: BaseShield, IFlying

you then only have to implement IFlying.

Not all Shields fly, only FlyingShield.

Now, if you want to know what are all of the wieldable items on a player are...
loop

if(item is IWieldable)
  (item as IWieldable).Wield();

The BaseShield and FlyingShield are also IMetal.
So, a metal corroding blob encases a player...its attack could loop through all items on a player to

if(item is IMetal)
  (item as IMetal).Corrode();

Corrode being a method in IMetal.

But, all the swords also implemented IMetal, so those get Corroded as well, all helmets, etc.

You were talking about Questable items... Derive a Quest key from BaseKey:
class QuestKey: BaseKey, IQuestItem

Then emplement the required Quest data... such as, what the quest number is. Only QuestKeys are quest-items, all others have whatever features are necessary to being a key.

class QuestShield: BaseShield, IQuestItem ... same thing.

IQuestItem would probably look like this:

interface IQuestItem
public int QuestNumber;
public void QuestComplete();
public void QuestStart();

Then each item that implements IQuestItem provides those three things and BAM - it's a quest item.

Sorry, I love interfaces. It is possible to get interface-happy and do it everywhere.
If you're still not sold on interfaces, the only other way I can think of, other than just an internal collection of stuff, is the Decorator pattern of coding. It allows one to dynamically attach new properties to a class. I haven't used it, but it's also similar to what you want.

I disagree with the assumptions you imposed about what a base shield is, and the sheer quantity of classes one would have to define with essentially copy-paste coding just for shields alone. Not all shields are metal. Some are wooden. In some settings, they may be riot shields (plexiglass?). In not all cases are they viable weapons either; some tower shields, at least in some game systems, may not be used as such. So your BasicShield and FlyingShield iterations, just from those expansions (and there's probably more) means you combinatorially have to add the following code clases (and C# files):

• BaseWoodenWieldableShield
• BaseMetalWieldableShield
• BasePlexiglassWieldableShield
• BaseWoodenShield
• BaseMetalShield
• BasePlexiglassShield
• FlyingWoodenWieldableShield
• FlyingMetalWieldableShield
• FlyingPlexiglassWieldableShield
• FlyingWoodenShield
• FlyingMetalShield
• FlyingPlexiglassShield

This is clearly out of hand, and will continue to grow exponentially in order for every combination to be available to use by non-coding builders. Either we add more properties to shields as we decide we need them, like material, or add a MaterialBehavior, or something else altogether. 100% interfacing is ridiculous already.

Yup, I agree. That's part of the reason why I implemented base behaviors as classes and not interfaces. The other reason is that I don't want builders to have to implement basic behaviors for each and every item. So we have to look at this from a builder's point of view. I want to be able to clone from a base item type, and have functionality built-in from the get go. Otherwise, this will be a WHALE FAIL with builders. I know I would shun a MUD that made me jump through those hoops.

Every item that is metal has to implement Corrode? Some of them will do it different and we're reinforcing significant copy-paste code here. Much better to have Corrode be a skill the Mobile can utilize, which has a single implementation, which looks for IMetal items the player is wearing and damages one of those items if found?

MUDs tend to have thousands, often tens of thousands of items, rooms, mobiles, and the like. Having every mildly unique combination of item behaviors require a new base class is unwieldy.

Corrosion is something that is perfect for the Effects system. Everything in the MUD has a collection of effects. We would just "publish" an effect to the item in question, and the effect would do its things. At least that's how we envision them working.

Okay, the material is an enum.
There, you're down to two classes again.
In this case, I agree Corrode should be in the Monster's skill list, none-the-less. It doesn't require tons of copy-paste code.
If designed appropriately, it prevents just that.

Sorry, my post was being worked on while yours was, you're right - the Corrosion effect would be perfect for the Effects system.

David and I just got done with a rather long IM on the subject that this thread morphed into, I'm gonna do some homework and then post up a more accurate paraphrased log of it.
But, here is the essence of the chat...

Essentially, both - interfaces and the behavior system. Each system has downfalls that the other covers.

I wasn't aware that there was ANY previous work on behaviors, so seeing the currently planned implementation that is in the code relaxed me on the system a bit.

Yeah we had a good IM debate, and the short of it is that we feel there should be a good compromise: Interfaces for core stuffs, Behaviors for specifics.

[Redacted description of interfaces we actually nixed later.] If you care about making shields that are good for the 'shield bash', add a ShieldBashableBehavior to represent shield with spikes or the like. I think we agree IMetal is a bad idea, and that material could be a property of Things, even if that usually defaults to 'unknown'.

Too many interfaces is bad, especially in compounding combinations, but they are performant and more direct to query.

BehaviorsManager is less performant (having to iterate a list), but allows less impact to DB and building scenarios and such upon expansion.

[ed. update 2021] Actually at this point even defining "metal" things would probably come down to a MetallicBehavior or CoreMaterialBehavior with an enum to describe the core material type or whatnot... which could be used for, say, corrosion attacks to decide if they're going to add a CorrodedEffect or DamagedEffect or further destroy the item outright, etc. Such composition approaches mean a given MUD implementation is free to either care about core materials, or not care about core materials if they don't want to.

---

The intent of IContainerFurniture was to enable containers to have the same sorts of furnishings that doors can, such as locks and traps. We can probably actually call it something else altogether, and use the same thing for doors and containers. Maybe we just have a LockingBehavior (with properties for key ID, etc) and TrapBehavior (with properties for whether the trap sets off upon unlocking or opening, difficulty to spot or disarm it, the Effect to clone to the target, and so on).

I think that's a good idea, but I was listing things I think are useful for the interface structure.

A lock can be destroyed, so a dynamic behavior.

I'm trying to think now from a builder's perspective.

list exits
exit34 in room53
> create door exit34
created door564 on exit34
> apply LockBehavior 64 door564
door564 now has LockBehavior and responds to KeyBehavior with a property of 64
> apply TrapBehavior 56 door564
door564 has TrapBehavior 56 applied to it (FireTrap)
> create key
key87 has been created and is in your inventory
> apply KeyBehavior 64 key87
key87 has KeyBehavior 64 applied to it
> drop key
key87 has been dropped in room53

...or something like that.

Yeah, that's basically what I was saying, that while the intent of the interface made sense, it does really make much more sense as Behaviors of the door. Much more consistent.

The builder's experience portrayed there isn't very great; at the very least we could have them type 'FireTrap' instead of an ID there. Anyway, that's obviously not the point you're making here. Just to remind everyone, I do still have a pretty in-depth in-game builder design in the works, and hope to put more time into it and post it maybe this weekend. I don't have a User Story started for it, but it will very much help for this, and I plan to do that now.

I have no thoughts yet on the out-of-game builder design, and haven't looked at the existing code base there either. (I do have to wonder how one would isolate areas they built at home, send them to a MUD admin, and how the admin would import the data, or if some other process would be involved like exporting an in-game builder sequence of commands used to replicate the area. Darn, now I'm getting totally sidetracked!)

Ideally, I think a builder's experience should be almost all via external tools. We're using .Net, it has tons of features that would work for what we'd need in a builder tool set.

Are you suggesting: > apply TrapBehavior FireTrap door534?

Or > apply FireTrap door534?

Or > apply FireTrapBehavior door534?
One of those will make me pull my hair out...guess which one?

---

[Mar 2010]

Being new to C#, and having been frustrated with the C# code my first annoying newbie question is:

C# Interface is equivilent to being a .h file? The Programming C# i have says Interfaces are just for definitions and not implementations, so the question is do I use an interface the same way as I would do .h file?

There is some similarity to a .h file, but an interface is completely optional. An interface is essentially a contract which helps enable things like polymorphic code in certain circumstances. Unlike C/C++, in C#, any given class is only allowed to inherit from a single concrete base class, but it IS allowed to inherit from as many interfaces as it likes. The class must then fulfull the interface contract in order to compile. Often, inheritence is used to make guarantees about certain behaviors that a class supports.

For example, if we have the IStackable interface which lists the Split and Combine methods and a Count property... When you then make a class Coin : IStackable, then Coin has to fulfill methods for Split and Combine and provide a Count property. Elsewhere in the code, say for the Drop action processing of the "drop X object" pattern, all you need to know about the target object is that it "is" IStackable, before you can if targetStackable.Count >= X then targetStackable.Split... and so on. Polymorphism can be quite prevalent in C# code, and makes tons of things much simpler when used right. :)

We have too many interfaces in WheelMUD code right now. The way a lot of the interfaces are currently used in WheelMUD is something that seems to be intended for test-driven-development: this is when the interface essentially maps exactly to a class, rather than describing some comon, reuseable sub-behavior of multiple classes. However, since we essentially aren't doing TDD, we've been removing some unneeded interfaces where we can, and using concrete base class inheritence instead. For example, IIRC (I can't look at the code ATM) Stackable is a class rather than just an interface, and Currency derives from Stackable instead of just IStackable. If we then wanted Coin and PaperBill classes, we could derive them from Currency; we would probably want such a PaperBill class automatically gain the IsFlammableBehavior during its constructors.

Ideally, we want to strike an intelligent balance between interfaces, concrete classes, and extensions (such as the Behaviors system). For example, we could choose to have an IFlammable interface instead of using a Behavior, but that would require every object type which could potentially be flammable, to fulfill the interface, even for object types which are only sometimes flammable. In this case, it's better to have the Behavior.

Also, I believe interfaces sometimes help with interfacing across application boundaries, and may be a basis for utilizing things like MEF effectively. At work, I've never actually had to expose interfaces instead of sharing concrete classes in a shared Project (DLL) to get things to work together well. So mileage may vary based on the complexity of projects, boundaries, and so on.

---

[Moving DI topics to #149.]