对单例 "manager" 对象的静态引用的缺点?

Cons of Static References to singleton "manager" objects?

我正在用纯 Java 制作游戏(在一定程度上是一种学习经历,因为我对编程还很陌生)并且我发现我不断传递相同的参考资料,即"manager"类型的高级单例对象:World、PlayerManager、EnemyManager、TargetManager、ItemManager等

目前我只对我的最终 Constants/Utility 方法 class 进行静态引用,其中包含类似于 java.lang.Math.

的内容

我在想的是,对这些对象进行静态引用会大大减少传递的数量,并且 this.boop = boop'ing 我将不得不做,但是 感觉 不好的做法,我不知道为什么。

这样做有什么缺点?

编辑:

为了避免使用 Static,我可以创建一个 ReferenceManager 对象并传递它,但这似乎不必要地迟钝。

pro 显然是性能:如果您可以以更少的步骤访问所需的实例,那么您可以更快地开始使用它。此外,如果您在应用程序启动时初始化这些 "singletons",则当其他模块尝试访问时没有命中,因此您的单身人士甚至不需要 getInstance() 实现中典型的 if null then instantiate 逻辑.

一个con是高耦合。现在你的模块都知道这个实例以及如何访问它。这使得维护以及单元测试、模拟等变得更加困难,因为您的模块只知道 that 实例。此外,您不能以一种或另一种方式更有效地实现 TargetManager 的第二个实现,并在启动或动态地。

另一个缺点是单身:现在你不能再有第二个了World。它可能永远不会出现,但如果你制作一个 server/client 应用程序,服务器可能会跟踪多个 World 实例,这将变得难以重构。您可以使用 world1.get()world2.get() 之类的东西,并且只有两个单例,现在您的模块需要知道要获取哪个。现在一切都需要知道标准和访问方式,这会使事情变得非常复杂,而如果你传递一个引用(本质上只是注入),那么每个模块对它的环境的了解就更少了,这又是一个耦合。

在某些情况下,例如 OSGI,会使用类加载器,因此在某些情况下单例并不是真正的单例。

我敢肯定还有一些其他有用的博客文章和此类在线文章反对在某种情况下使用单例。

除此之外,游戏编程是关于捷径,所以如果您知道您不必担心任何这些情况,那么不在代码层中传递引用就是性能上的胜利,直接访问而不是某种注册表查找是另一种方法。在系统编程中,你今天走的捷径明天有时也会让你走弯路。