C# 冒险游戏的类设计

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

我从一个非常基本的类设计开始，它使用了继承（ItemInstance->EquipmentInstance），但这并不奏效，因为我希望以后的设计选择更加灵活，而且我确信我想要可掠夺的NPC（例如小动物）

所以我想到了创建一个基类的想法，它可以保存一个item实例、npc实例或两者：

public class Instance {

    public int instanceId;

    public ItemInstance itemInstance;
    public NPCInstance npcInstance;
}

通过这种方式itemInstance可以保存数量、武器或装备的字段，当然NPC状态可以保存当前的生命值、法力值和所有这些内容

但我不确定这是一个好的解决方案，还是会导致缺点。当然，我也对其他选择持开放态度

---

谢谢

像Minecraft这样的实体基类似乎工作得相当不错。然后是属性可配置的基本项类

在类设计中尝试并预见未来是很好的。但我建议大家阅读敏捷开发。特别是，只为下一个需求编写代码，但为每个需求重构代码。当您处于开发的早期阶段时，几乎不可能提前告诉您最佳的类设计是什么样子的

保持简单还意味着努力使您的类反映您试图实现的任何现实。在你的情况下，我会说物品是NPC的财产，因为NPC会随身携带物品（或者在小动物身上）。如果您认为系统中的每个类都有共享行为是有理由的，那么NPC和Items都可能继承实例。从实例继承只是为了共享一个int属性似乎有些过分

---

好的类设计遵循这个原则。

虽然这个问题在这里有点离题，但我想指出，使用实体的继承通常是一种设计味道

继承基本上是在具有类似行为的类之间建立关系；在这一点上，可能需要考虑实体和对象之间的区别

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

• 对象通常是封装行为的类；可能与实体或其他对象交互，也可能不交互。对象通常具有某种内部状态，但这是与行为相关联的状态，而不是用户会考虑的内容（例如，撤消/重做操作列表、

  IsInitialized

  标志或某个非托管资源的句柄）

考虑将对象和实体分开；您可能会发现，通过这种方式，您最终需要的实体要少得多。例如，您不必创建多个类，例如

剑

、

枪

、

斧

等。您可能会得到一个名为

武器

的实体，其中

以数据表示“剑”、“枪”、“斧”

。（实体建模与面向对象建模是一种非常不同的思维方式；对于实体建模而言，从关系数据的角度考虑可能会有所帮助）

通常，继承是关于创建具有类似行为的类；通常，一个设计良好的行为类最终会以其用途命名-例如，

枪

听起来像一个实体，但

枪伤害计算器

听起来更像是一个有用的东西，甚至可以与

AxeDamageCalculator

或

CandlestickDamageCalculator

等一起放入合理的层次结构中

---

总之，继承是一种IS-A关系的类比适用于行为，而不是属性。大多数软件的现实情况是，用

动物
来描述
猫
，或者用
车辆
来描述
汽车
通常是无济于事的-通常情况下，实体“基类”最终是相当无用的，实际上并不能帮助您编写程序
 对我来说，这似乎是一个奇怪的包罗万象的解决方案，你会到处问‘这是什么东西？’。在过去使用过一些发动机之后，我更喜欢您的第一个概念。项目就是项目，NPC就是NPC。如果你不想让小动物被掠夺，那么他们有一张空的掠夺桌。有时，您需要抵制超出需求的设计冲动。你真正需要多少灵活性？灵活性（复杂性）总是伴随着相关的成本。RPG Maker是一个（非常）简单的引擎，它以Ruby的形式提供所有（高级）源代码。您可以在不购买引擎的情况下找到这些脚本。我会通过检查字段是否为null来完成。嗯，我真的需要很大的灵活性，例如，戴一顶NPC（如浣熊）作为帽子和诸如此类的疯狂东西也是可能的是的，但在我看来，这是一个糟糕的设计。您已经实现了一个类，它是一个功能的抓包，现在消费者有责任决定如何使用它。至于你的例子，不，你不想戴NPC当帽子。你想戴上一件物品作为帽子，但是你的游戏如何管理NPC->物品的转换取决于你，但是不要把这两个概念混为一谈。你戴的是物品，不是生物。这不是一个合适的问题。请同时询问，rpg在这个上下文中指的是专业人士