【问题标题】:Interfaces for Player Attributes玩家属性接口
【发布时间】:2015-04-27 15:13:57
【问题描述】:

表示播放器类的每个属性的接口是否合适?这有问题吗?

随着属性被添加到模型中,接口也会导致长声明。

public class Player : INamed, IEnergy, IInventory, IMana, ...
{
    public string Name { get; set; }
    public int Energy { get; set; }
    public int Mana { get; set; }
    public Inventory Backpack { get; }
    ...

}

【问题讨论】:

  • 我不明白。名称、能量、法力等是玩家的属性 - 因此它们应该是类中的属性。你为什么要为每个人创建一个界面?
  • 没有。代表玩家每个属性的属性是合适的。如果您选择一名球员,球员是Mana 或球员是Energy 听起来合适吗?你会单独使用这些接口之一吗?这样做会给您带来编程优势吗?如果没有,你的方法 == 额外的噪音。
  • 我认为你应该阅读thisthis

标签: c# interface


【解决方案1】:

对我来说,这告诉我并非所有玩家都有名字、能量等。对于基本游戏,所有单位通常都有某种名称和一系列生命值,这些生命值表示该单位可以承受多少伤害.

如果您游戏中的所有单位具有相似的属性但不同值(也许牧师可以比士兵承受更少的伤害,但可以移动得更快,因为它不有盔甲),你可以定义一个接口来指定你的单位的行为,因此你可以有这样的东西:

public interface IBaseUnit 
{
     int HitPoints
     ..
}

然后,每个特定单元都有自己的实现。话虽如此,我认为这些单元在大多数情况下都会以类似的方式运行,因此,使用抽象类而不是层次结构顶部的接口可能更有效。

【讨论】:

  • @DaneshM.:请提供更多信息。实体之间共享哪些属性,哪些不共享?
  • @DaneshM.:我认为那些有库存的单位将属于特定类别的单位,同样适用于那些有法力的单位。
  • @DaneshM。你对类的理解是错误的。 Player 类将具有某些属性 - 因此所有 Player 对象也将具有这些属性,因为它们 Player。这就像一个人将创建一个类 Dog,然后他会希望其中一些有年龄,而另一些则没有。这只是假的。
  • @Eminem:是的,这就是我试图引导 OP 实现的目标。
  • @DaneshM。我是说你不能有两个具有不同属性的 Player 对象。要么全部,要么不。当您考虑它时,这是非常合理和合乎逻辑的。创建一个 Player 类,该类具有所有玩家都具有的某些属性(每个人都有名字、法力等)。然后您可以创建一堆 Player objects 并为其属性分配一些值。需要注意的是,类通常有方法。即一个 Player 类可以有一个 Attack 方法等。
【解决方案2】:

在我看来,你需要的是一个类层次结构,而不是一堆接口。与其构建不同角色可以拥有的大量“属性”池,不如建议您使用一些具体单元继承的基本抽象类对某种层次结构进行建模。

一个基本的想法:

abstract class Character
{
    String name
    int hitpoints;
    IList<Item> inventory;
}

abstract class Spellcaster : Character
{
    int manapoints;
    IList<Spell> knownSpells;
}

class Mage : Spellcaster
{
    // Mage specific stuff
}

class Necromancer : Spellcaster
{
    // Necromancer specific stuff
}

等等。显然,您建模的类将取决于您正在制作的游戏类型。

【讨论】:

    猜你喜欢
    • 2021-06-08
    • 1970-01-01
    • 2016-03-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-11-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多