从一个接口继承对象时，如何将它们组合到一个列表中？

Question

I'm learning C# and trying to do simple object oriented exercise.

I have three weapon classes, "Bow,dagger,Spear", so I made one interface and inherited from this interface IWeapon.

Now user must choose one of the weapon, so I want to make Collection of weapons and I'm trying to make list of IWeapons, is it correct way? Isn't it bad practice to make list type of IWeapon ? Because of, I know that Interfaces are like a contracts, and I think it's a bad idea to make List with Interface type. One way is to change interface to an abstract class, but I want to use Interface.

 private static List<IWeapon> weapons = new List<IWeapon>();

Is it correct way or not ?

Answer 1

The only problem with your solution is that static members should be thread-safe. It's like a convention among C# developers. So either change it to a non-static and, preferrably, readonly:

private readonly List<IWeapon> weapons = new List<IWeapon>();

Or use a thread-safe collection:

private static ConcurrentBag<IWeapon> weapons = new ConcurrentBag<IWeapon>();

Answer 2

There's nothing wrong with using interfaces as values for lists.

However, this may not be appropriate to your specific case. You said you'd like the player to pick from a list of weapons. Now consider the follwing scenarios:

1. You have a single player in your game, and he chose a single weapon. You have created a whole list worth of weapon instances that no one will ever need or use. This just wastes memory.
2. You have multiple players in the game, and they both choose the same weapon. This could be even worse. If you assign the weapons like this: player.Weapon = weapons[1] , then both players will have the same instance of the weapon. If one user assings buffs to his weapons, or maybe if the weapon degrades or breaks, both the players weapons will be affected, since it is, in fact, the same weapon. Think of it like this, both you and I would like a chocolate cake. The store can either give us both the same piece of cake, in this case, if you eat it, I will have none. Or they can bake us both new cakes, so each of us can have his own.

The appropriate solution in this case is to save the types of weapons and present these to the player. Then create a new weapon instance according to the player's choice.

There are several different ways to do this, the simplest of which is to create an enum with the weapon types and present these to the player.

So instead of the list, you can have:

public enum WeaponType
{
    Bow,
    Dagger,
    Spear
}

And now you need to create the instance of the weapon the player chose:

public IWeapon CreateWeapon(WeaponType weaponType)
{
    switch(weaponType)
    {
        case WeaponType.Bow:
        // Create Bow...
        case WeaponType.Dagger:
        // Create Dagger...
        case WeaponType.Spear:
        // Create Spear...
    }
}

This is the basis to the Factory design pattern. I would highly recommend you to take a look at it. Here's a good place to start: http://www.dofactory.com/net/factory-method-design-pattern

Answer 3

I have two thoughts on this:

1. I can easily imagine a situation where one would want to use a collection of a particular interface. For example, if you were writing a download queue. You would have weapons and shields and players and villages which all implement an IDownloadableThing interface. Your queue code would have a collection of IDownloadableThings because it doesn't care what its actually downloading, it just cares that that thing know what its URL or file path or whatever is.

2. I'm a little wary of developer edicts. There are good ideas and traps you should be aware of in any language, but context can change everything. When you are trying to figure out if 'Weapon' should be an abstract class, ask yourself a couple things. Should a class implementing Weapon also be allowed to be a Shield? If locking down multiple inheritance is important, then abstract classes are the way to do that. Will there be a lot or any common behavior that classes implementing 'Weapon' will want to share? For example, is there a CalculateDamage() method that's basically identical between all 'Weapon' implementations. Once you have answers to what a class of interface's purpose is, then it'll be easier to choose to violate a development guideline because the situation requires it or re-think your approach.