层次考虑答案

【问题标题】：Hierarchy consideration层次考虑
【发布时间】：2011-11-29 00:52:46
【问题描述】：

我正在制作一个游戏，它的当前类层次结构为 GenerateStats -> ClassStats -> CreateCharacter。我觉得这可能会倒退。统计没有职业统计，职业统计没有字符。我要倒退吗？应该是 CreateCharacter -> ClassStats -> GenerateStats 吗？感谢您的意见！

【问题讨论】：

由于我不知道这些东西是什么，所以我无法知道您是否正确。
对不起，我做了一个编辑，提到这些是我层次结构中的类。道歉

标签： c# class data-structures hierarchy

【解决方案1】：

这些在类层次结构中都没有意义；类层次结构代表名词之间的“是一种”关系；你列出的那些东西是动词。这些应该是类的方法。类应该是CharacterGenerator。

【讨论】：

谢谢指点；我会记住这一点！我正在赶上我的编程并努力学习。

【解决方案2】：

CreateCharacter 似乎不应该是 ClassStats 的子类，但由于我不知道任何类中的实际内容，我无法确定。

【讨论】：

ClassStats 是角色力量、韧性、智力和智慧应该被操纵的方式。根据他们选择的类别，统计数据会相应变化。
我刚刚将 CharacterClass 作为超类。然后我会有战士或法师或任何继承自它的东西。您不应该需要 CreateCharacter。这应该在 CharacterClass 构造函数中。

【解决方案3】：

在我看来，你不会倒退。继承变得更具体 - 例如Apple 继承自 Fruit（它实现了 IEdible！），它继承了 Object。不是反过来。当然，你的课程流向哪个方向并不完全清楚，所以我不确定。只要确保基类最不具体，派生类比基类更具体。如果您经常使用 private new xxx MyFunction() { //... 跟踪方法，则表明您的做法是错误的。

【讨论】：

GenerateStats 创造了特定角色的基本力量、韧性、智慧和智慧。 ClassStats 详细说明了如何更改这些属性，战士比法师强。最后 CreateCharacter 实际制作了角色、名称、统计数据，以及最终角色将拥有的其余物品。
@user1056607：那些最好是函数，然后……面向对象编程并不意味着一切都必须是一个类。
类比函数更消耗资源吗？
@user1056607：可能。不过，这不是问题——您只是不要为此使用类。这是语义。
@user1056607，如果它使事情变得更难理解并且人力资源通常比 CPU 周期更昂贵，那么它可能会耗费人力资源。

【解决方案4】：

改写（正如 Eric 指出的那样，使用动词会产生误导），我相信您的问题是：

CharacterGenerator 是否应该是一种 ClassGenerator，而 ClassGenerator 本身应该是一种 StatsGenerator？一些注意事项：

您是否希望从 ClassGenerator 或 StatsGenerator 派生其他类型的东西？如果没有，则不需要继承。
您是否有其他代码希望能够使用任何 StatsGenerator 或任何 ClassGenerator？如果您没有使用基类进行操作的代码，则不需要基类。

根据名称，我认为您真正要描述的是组合关系。看看这个表达是否更像你想要做的：

您有一个 CharacterGenerator，它使用一个 ClassGenerator 来生成角色类和一个 StatsGenerator 来生成角色统计信息。结果是一个包含 Class 和 Stats 的 Character。

编程时有很多方法可以建模和解决问题；最好选择最简单的方法，而继承关系会增加复杂性。如果您打算使用它，那么您应该有充分的理由引入这种复杂性。

另外，正如其他人所指出的，您不一定需要定义一个类来复合行为。在某些情况下，一种或几种方法就足够了。也就是说，在“太小”（方法很少的小类）而不是“太大”（一些充满各种不同方法的大类）方面犯错并不一定是坏事。找到正确的平衡是很棘手的，所以实验一下。

【讨论】：

感谢您考虑的想法。我正在考虑将 StatsGenerator 重新用于我将在游戏中放入的怪物。当我包含怪物时，该层次结构路径将如下所示：GenerateStats -> MonsterRace -> GenerateMonster。 MonsteRace 是什么怪物，GenerateMonster 是针对特定怪物的。