在 Objective-C 游戏中使用枚举或抽象基类
上下文： 在游戏中，完成每个级别后，会根据玩家表现存储评级：差、好、优秀。 评级随后用于评估整个游戏。
问题： 评级对象是否应该包含作为枚举 {RatingPoor、RatingGood、RatingExcellent} 的评级选择，或者我应该创建一个带有子类 RatingPoor、RatingGood、RatingExcellent 的抽象基类评级。
其他详细信息
评级没有复杂的行为，它们只是以非常低的频率（例如每分钟）根据游戏统计数据生成的。他们被分配到一个集合，并在游戏结束时进行平均，以生成排名（如学员、飞行员、上尉、海军上将）。在关卡结束时，评级会显示为图标（想想星星，就像《愤怒的小鸟》中的那样）。当玩家暂停或暂停游戏时，它们也会被存储。
在这种情况下，我也希望知道如何决定枚举与子类。
Context:
In a game, when each level is completed, a Rating is stored based on player performance: Poor, Good, Excellent.
The ratings are later used to evaluate the game play as a whole.
Question:
Should the Rating object contain a rating choice as an enum {RatingPoor, RatingGood, RatingExcellent} or should I make an abstract base class Rating with subclasses RatingPoor, RatingGood, RatingExcellent.
Other details
Ratings don't have complex behaviors, they are just generated from play stats at a very low frequency like every minute. They're assigned to a collection and averaged at the end of a game to generate a Rank (like Cadet, Pilot, Captain, Admiral). At the end of a level, the rating is shown as an icon (think stars, like in Angry Birds). They also get stored when the player pauses or suspends the game.
I would also appreciate knowing how to decide on enum vs. subclass, given this context.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这种情况很基本，您应该只使用
enum。当某些东西可以用整数（模式，设置，或者在您的情况下，评级）表示时，我通常使用enum。仅当您的评级包含其他属性或关系时才需要子类。This situation is basic enough that you should just use an
enum. I typically useenum's when something can be represented by an integer (a mode, a setting, or in your case, a rating,). A subclass is only necessary if your ratings would include additional attributes or relationships.我认为子类对于这种情况来说太过分了，因为听起来您没有为每个评级附加任何特定的方法。我会使用枚举。
我不是软件设计方面的专家，但我通常会错误地使用最简单的数据结构来完成工作——一般来说，如果问题不需要你有处理数据的方法，那么类将是比必要的更重量级。
I think that a subclass would be overkill for this situation, as it doesn't sound like you're attaching any particular methods to each rating. I would use an enum.
I'm no expert in software design, but I generally err towards using the simplest data structures that will get a job done-- in general, if the problem doesn't require you to have methods travelling with the data, a class would be more heavyweight than necessary.