冒险游戏的类设计

Question

我目前正在进行一次小型冒险，想知道什么是项目和npc实例的最佳类设计。

我从使用继承（ItemInstance - ＆gt; EquipmentInstance）的非常基本的类设计开始，但这不能很好地工作，因为我希望在以后的设计选择中更灵活，因为我确定我想要可掠夺的NPC（例如小动物）。

所以我想出了创建一个可以容纳项目实例，npc实例或两者的基类的想法：

public class Instance {

    public int instanceId;

    public ItemInstance itemInstance;
    public NPCInstance npcInstance;
}

这样，itemInstance可以保存数量，武器或装备的字段，当然npcInstance可以保存当前的生命值，法术力和所有这些东西。

但我不确定这个是否是一个好的解决方案，或者它是否会导致弊端。当然，我也愿意接受替代方案。

谢谢！

Answer 1

虽然这个问题在某种程度上偏离了主题，但我想指出，使用实体的继承通常是一种设计气味。

继承基本上是关于在类似行为的类之间建立关系;这是值得考虑实体和对象之间差异的地方。

• 实体通常表示与您的应用程序的功能要求相关的某些事物的状态（例如，存储有关信息的“用户”实体用户）。
  实体通常没有太多行为，因为混合状态和行为通常会导致违反SRP（单一责任原则）的臃肿，不灵活的类，并且可能需要在其他地方使用更复杂的“if / else”代码才能正确管理它们。

• 对象通常是一个封装行为的类;并且可能或可能不与实体或其他对象交互。对象通常具有某种内部状态，但这将是与行为相关联的状态，而不是您的用户会想到的内容（例如，撤消/重做的动作列表，isInitialised标志或句柄一些非托管资源）。

考虑将你的对象和你的实体分开;您可能会发现最终需要这么少的实体。例如，您可能最终只能使用名为Sword的单个实体Gun来创建多个类，例如Axe，Weapon，"Sword", "Gun", "Axe"等。用数据表示。 （实体建模是对OO建模的一种非常不同的思维方式;对于实体建模，它可能有助于用关系数据来思考）

通常，继承是关于创建具有类似行为的类;通常，设计良好的行为类最终会以其目的命名 - 例如，Gun听起来像一个实体，但GunDamageCalculator听起来更像是可以做一些有用的东西，甚至可能与AxeDamageCalculator或CandlestickDamageCalculator等等一起构成合理的层次结构。

总结一下 - 继承的类比是 IS-A 关系适用于行为而非属性。大多数软件的实际情况是，根据Cat或Animal来描述Car对Vehicle来说通常是无益的 - 通常是实体“基类“最终变得毫无用处，实际上并没有帮助你编写你的程序。

Answer 2

像Minecraft这样的实体基类看起来确实很不错。然后使用属性Equippable

创建Item类

Answer 3

尝试预测课堂设计的未来是件好事。但我建议阅读敏捷开发。特别是，代码仅用于您的下一个要求，但是针对每个要求进行重构。如果您处于早期开发阶段，几乎不可能预先知道最佳类设计会是什么样子。

保持简单也意味着努力让你的课程反映出你想要实现的任何现实。在你的情况下，我说物品是NPC的财产，因为携带物品（或在小动物的情况下）。如果您认为系统中的每个类都有共享行为，那么NPC和Items都可以继承Instance。从Instance继承只是为了共享一个int属性看起来有点矫枉过正。

良好的课堂设计遵循SOLID原则。