如何设计一个可以在其他项目中复用的类答案

【问题标题】：How to design a class that can be reused in other projects如何设计一个可以在其他项目中复用的类
【发布时间】：2019-03-27 16:14:34
【问题描述】：

我们想要一个用于游戏的椅子课程。我们如何创建这个类以便它也可以在另一个游戏中工作？并通过考虑可靠的原则。

例如，假设我们有 2 款游戏：一款是扑克游戏，另一款是类似侠盗猎车手的游戏。在扑克游戏中，班级应该有id、playersited() : player、state : full、empty、reserved。我现在可以想到这些属性。但在第二场比赛中，椅子不需要id 或playersited() 函数。那么如何设计这个可以在其他游戏中重复使用的类呢？

【问题讨论】：

我就是不明白。
你没有得到哪一部分？
简单回答：不要。这似乎是一个很好的例子，不尝试重用/过度共享。试图过于通用会导致复杂性增加，你最终会得到一个糟糕的泛型类而不是好的特定类。阅读composition over inheritance 并继续努力。
谢谢，这是一个直截了当的答案。
@kigiri 仅基于标题，是的....您应该将其写为答案！

标签： uml class-design reusability

【解决方案1】：

您正在寻找可以在不同游戏中重复使用的通用游戏对象，但根据游戏的不同，它可能具有不同的属性和不同的功能。

简单的 UML 答案

如果您只是从 UML 的角度来看它，那么这个设计问题很简单：绘制一个类GameObject，将您想要通用的属性和操作放入其中。然后在您不同游戏的模型中，只需使用继承创建一个专业化：PokerObject 和GrandCloneObject，您将在其中添加游戏特定的属性和操作。

但是，当您开始设计与其他类（可重用或不可重用）的链接时，这种明显的简单性会隐藏很多难点，当您开始研究它们的交互时甚至会更难。

这种通用设计的局限性

此外，您还需要 SOLID 设计。然后，LSP 将通过强制您保持对象之间的可重用交互仅依赖于公共部分来降低可重用性。

如果最终只有 10% 的设计是真正可重用的，而 90% 是特定于游戏的，那么您将没有任何优势，只会通过人为地拆分类使代码更加复杂。在这里，我将联合@kigiri 的评论：“只是不要”

更好的方法

但是，如果您正在寻找真正可在更高规模上重复使用的东西，那么如果您不查看 Chair、“武器”、“物品”，而是查看更高级别的抽象，那么有一个解决方案。

在这里，我只能推荐您阅读 Mike McShaffry 的 Game Coding Complete 一书，它将向您介绍一种非常强大的架构模式，称为 Entity Component System。

这个想法是放弃具有非常具体的类的深度嵌套的类层次结构，但更喜欢一个非常扁平的模型：

实体：这些是游戏中使用的主要对象，无论游戏是什么
组件：这些由实体拥有，代表实体可以具有的属性（例如 LivePoints、Force、...），或实体应具有的行为（例如，renderFixedObject、soundWhenClicked 等..)。

这种设计允许开发高度可重用的对象，允许在可重用实体和组件的顶部添加游戏特定组件。

【讨论】：