重新利用.net类型系统 - 坏主意？

Question

我正在玩写一个项目制作系统，我有一天可能想把它放进游戏中。有Recipe个指定了它们需要的成分和它们产生的成分。

我希望食谱灵活，这样他们只需要一大类成分，而不是一个确切的成分。例如，武器刀片的配方可能只是说它需要金属，而不是钢铁。配方必须验证给出的成分是否在可接受的范围内。某些材料可能属于多个类别。

然后我有一个可能很精彩，可能是疯狂的想法。 .net类型系统已经实现了！因此，对于每种材料，我添加了Type类型的属性，并使用IsAssignableFrom来验证成分的兼容性。

我有一个看起来像这样的文件：

public interface ItemType { }

public interface Material : ItemType { }

public interface Metal : Material { }

public interface Gold : Metal { }
public interface Silver : Metal { }
public interface Iron : Metal { }
public interface Steel : Metal { }

public interface Wood : Material { }
public interface Coal : Material { }

等等。这些都没有实施过。我只是为了自己的目的借用内置类型检查。

这有什么不妥吗？

编辑：实际问题

如果我已经足够清楚地解释我在尝试在这里完成什么，那么你会建议一个好的方法来解决它，忽略这种整个系统滥用的事情？你也会使用这个解决方案吗？

第二个问题，我在这里所做的事情有什么值得注意的地方吗？

Answer 1

  

这有什么不妥吗？

是的，一切。

1. 类和接口用于表达行为。您的代码中没有任何行为。您的代码不会错误地表达意图。通常，当您看到界面时，您希望它有一些方法并调用该方法。情况并非如此。
2. 与大多数普通游戏一样，在某种配置/资源文件中定义材料和配方是不可能的。因此，每次要更改材料或配方时，都必须重新编译。
3. 创建以某种方式相关的项目/材料将成为问题。例如，假设有多个工具，每个工具可以来自不同的材料。在您的情况下，您必须记下每个组合。在理想情况下，您可以运行几个嵌套for循环来创建每个组合。
4. 如果不创建它们的类，则无法以任何方式对参数化材质进行参数化。例如，您可能需要不同颜色的羊毛。你会怎么做？为每种颜色创建界面？或者使用某种枚举作为参数。但你必须为此创建课程。

更好的方法是简单的Item类，它具有标记集合。即使是简单的字符串就足够了。