如何避免编写Manager类？

我似乎一直在读，XxxManager在游戏引擎编程中使用样式类是一个坏主意，但是即使我尝试避免使用样式类，我也总是最终得到可以容纳所有参与者/实体/游戏世界位置并对其进行操作的东西。最终成为Manager另一个名字的if。

这真的是一个不好的模式吗？如果是这样，有哪些替代方案？

出于各种原因，“经理”类可能会出现问题。两个主要原因往往是：

• 名称不清楚（“管理” 实际上意味着什么，对于每种被管理的事物它总是相同吗？）
• 它们倾向于成为违反单一职责原则的功能桶（也就是说，类型应该做一件事）

这些原因之一通常是引起或暗示另一个的原因。

这些问题是牢记的好事，但不要让它们麻痹您实际制作游戏的能力。最终，没人会在乎您的类是什么或它们在做什么。他们将关心您的游戏。

将大多数“经理”分为两部分通常很容易：

• 存储实际对象并提供对它们的访问权的部分（您可以将其称为“存储”，“存储库”，“数据库”，“缓存”或其他各种东西。这是通常负责的类型在对象的生存期内；也就是说，从此类实例中删除或不再包含某个对象时，该对象将不复存在。

• 该部分处理的实际对象，并对其进行了一些工作。它可能会更新这些对象（然后是“更新器”或“模拟”），也可能绘制它们（然后是“抽屉”或“渲染器”）。否则可能会对他们产生其他影响 重要的是要根据其主要目的对其进行命名。通常，您应该为这种类型的实例提供第一种类型的实例的实例或对它的引用（仅处理对象生命周期的实例）。

一个合理的说法可能进行的是第一类的名称可能包括管理器（因为它“管理的生命周期”的一些对象）。如果您这样命名，世界将不会终结，尽管您可能需要经常忍受“不要叫事物经理”形式的下意识的反应，因此您可能想要避免这种情况。

当您阅读在评论中链接到的博客文章时，您将看到“如果是其他名称，则成为管理员”正是您想要的。在软件开发中，普遍的共识是全局变量是有害的，唯一的选择是任何数据都由其他数据保存。

命名类的问题FoobarManager是单词“ Manager”不能告诉您该类实际做什么。例如：

• 当它控制foobar的游戏机制时，可以将其命名为FoobarController。
• 当它实例化foobar，然后将控件委托给其他对象时，它是a FoobarFactory或FoobarBuilder。
• 当它在屏幕上绘制foobar时，它是一个FoobarRenderer。
• 当它监听foobars生成的事件时，它是一个FoobarEventHandler。
• 当它等待foobar发生某些事情时，它是一个FoobarObserver。
• 当它只是一组愚蠢的数据持有人而没有任何逻辑时，只需将其命名Foobars。

您可以将这些类中的任何一个命名为“ Manager”。但是，它可以执行所有这些功能。当您以后意识到需要上述功能中的另一个功能时，也可以将其集成到FoobarManager中。因此，您最终将得到一个“ 上帝对象”，它破坏了关注分离原则（每个班级都应该做一件事）。