我正在使用纯Java制作游戏（在公平的部分作为学习经验，因为我对编程很陌生）并且我发现我不断地传递相同的参考，即＆＃34;管理器＆＃34;键入高级单例对象：World，PlayerManager，EnemyManager，TargetManager，ItemManager等。
目前我只对我的Final Constants / Utility方法类进行静态引用，其中包含类似于java.lang.Math的内容。
我在想的是，对这些对象进行静态引用会大大减少传递的数量，而且我必须这样做，但感觉 >糟糕的做法，我不知道为什么。
我不必担心线程安全
我想静态引用的所有对象都是在游戏开始时创建的单身人士
做这样的事情的缺点是什么？
编辑：
为了避免使用静态，我可以创建一个ReferenceManager对象，然后传递它，但这似乎是不必要的钝。
答案 0 :(得分：1)
专家显然是性能：如果您可以通过更少的步骤访问所需的实例，那么您可以更快地开始使用它。此外，如果您在应用启动时初始化这些“单身人士”，那么其他模块尝试访问时就不会受到影响，因此您的单身人员甚至不需要if null then instantiate实施中典型的getInstance()逻辑。 / p>
一个骗局是高耦合。现在，您的模块都具体了解此实例以及如何访问它。这使得维护变得更加困难以及单元测试，模拟等，因为您的模块只知道那个实例。此外，您无法以某种方式再次实现TargetManager的更高效率并将其交换出来，或者在启动时或动态选择一个用于不同目的（OO实例替换）。
另一个骗局是单身：现在你不能有第二个World。它可能永远不会出现，但如果您创建服务器/客户端应用程序，服务器可能会跟踪多个World实例，并且这很难重构。您可以使用world1.get()和world2.get()之类的东西，只有两个单身，现在您的模块需要知道要抓取哪个。这可能会使事情变得非常复杂，因为一切都需要知道标准和访问方式，而如果你传递一个引用（基本上只是注入），那么每个模块都知道它的环境，这又是一个耦合加上。
在某些情况下，例如OSGI，有一些人在玩类加载器，所以在一些情况下，单身人士并不是真正的单身人士。
我确信还有一些其他有用的博客文章，并且在线推荐使用单身人士来处理这种情况。
除此之外，游戏编程是关于削减正确的角落，所以如果你知道你不必担心任何这些情况，那么不通过代码层传递引用是一个性能获胜，并且另一种是直接访问而不是某种注册表查找。在系统编程中，你今天削减的角落有时会在明天削减你。