对于OOP，应该尽可能频繁地将方法转换为对象吗？

Question

面向对象编程

过去我一直在玩Java，最近我一直在深入研究它和自学OOP。我目前正在创建一个基于文本的游戏，当我创建执行任务的方法时，我注意到如果我愿意，我可以将这些方法转换为对象。

我不太了解运行时或节省资源，所以我不一定要考虑这些变量，但是为了我的代码，它似乎可以清除一些空间。然而，另一方面，我将创建许多类，我觉得它们可能会弄乱我的目录。

~~例如，我创建了一个单独的类，用于为玩家创建个人资料。其中，有三种重要的方法。一个用于处理玩家的姓名选择，一个用于处理玩家的职业选择，一个用于完成玩家的决定。

我可以为这些方法创建3个对象，并通过这个类调用它们，这样可以清除代码中的空间，或者我可以将它们保留。

创建单独的对象是更明智的做法，还是让它们单独存在？

Answer 1

如果您不必创建许多对象实例，或者您可以很好地处理它，它不一定会改变您的代码样式，除非您必须在团队中工作并达成一致。

另外，我想你最好先通过这个链接澄清什么是“类”和“对象”。基本上，对象是从类创建的，包含状态和方法。

在您的示例中，我看到的是类而不是对象的控制器视图，您听说过MVC吗？如果您不知道，请查看此链接，因为它可以帮助您澄清比您想象的“类”和“模型”更多的内容

我希望我没有让你的想法更糟，但知道发生了什么很重要。

Answer 2

答案是视情况而定。

在OOP中，类（实例化时是对象）用于促进封装和抽象。有关更多详细信息，请参阅此SO帖子。

抽象是一种概念，即对象具有共同的特征，这可以通过类层次结构（ais-ab关系）和类组合（aHAS-ab关系）来证明。

封装是这样一种思想，即公共状态及其相互作用应该被视为具有定义良好的输入和输出的单个单元（或类），其中内部构件隐藏在表示它的类中。

归根结底，OOP是为了让程序员更容易编码。这意味着在确定程序内的交互时，更少的脑力开销，并且代码更清晰、更容易理解。

个案研究

在您的例子中，您有一个处理播放器配置文件创建的类，我们称之为PlayerProfileManager。根据封装，所有与创建播放器配置文件直接相关的行为（即方法）都应该在PlayerProfileManager中。

看抽象是事情变得有趣的地方。

PlayerProfileManager创建玩家档案并将该信息存储在某处。创建一个保存玩家配置文件所有数据的PlayerProfile类，然后让PlayerProfileManager在内部存储一组PlayerProfile对象，这可能是有意义的。称它们为它管理的配置文件。

PlayerProfileManager拥有一个PlayerProfile

您可以与管理器交互，以完成配置文件数据的所有获取和设置，管理器将该数据存储在配置文件对象中。

但是你有其他类型的个人资料吗？

如果是这样，也许您需要一个Profile类，该类包含任何概要文件都需要的所有概要文件信息。然后PlayerProfile继承自Profile，添加所有特定于玩家的数据。

PlayerProfile IS-A简介

然后您可能需要一个ProfileManager类，该类具有管理通用概要文件数据的通用方法。

PlayerProfileManager是一个档案管理员

现在我们可以利用多态性，这是OOP中的一项关键技术。如果您想处理所有概要文件数据，可以使用多态性很好地完成，因为它都继承自profile类。阅读链接了解更多详细信息。

但是永远记住，抽象只有在使代码更容易使用时才有意义。如果你只有一种类型的配置文件（并且只计划有一种类型），那么添加额外的层是没有意义的，因为它们会把你的代码弄得乱七八糟，而不是减少它。

结论

没有正确的答案，只要代码是干净的，并且属于一起的东西是在一起的（与关注点的分离有关）。

我鼓励你玩不同层次的抽象，以找出太多或太少的好处和陷阱。

Answer 3

最好的方法是生成易于维护、理解和扩展的代码。您描述的三个方法可能已经在正确的位置，但这取决于类本身应该表示什么。

您将其描述为一个玩家的配置文件，并且您描述的三种方法都操作该配置文件特有的数据，因此您的方法到目前为止听起来不错。

最重要的是：继续编码。不要为这样的细节而烦恼。它们通常不像教科书或课堂演示中看起来的那么重要，它们当然也不像那些喜欢一种方法胜过所有其他方法的狂热者会让你相信的那样重要。代码（几乎）总是可以重构的，而且（通常）在第一次时永远不会完全正确。

如果有人告诉你，当遇到这样的问题时，他们的方式是“最好的方式”或“正确的方式”，请忽略他们，并寻求其他人的建议。