Design patterns 单例模式性能缺陷

我在游戏中实现了单例模式来访问

实例

函数和变量，就像它们是

静态的一样。很好，我可以很方便地使用它。然而，根据我的理解，任何东西都有成本，这种易用性肯定有某种缺陷。问题是，经常使用
GameManager.instance.someOtherClass.someVariable
会不会花费很多？一般来说，
Singleton
的性能友好程度如何
 一般来说，Java应该能够优化经常使用的访问。我认为在你真正完成游戏并在衡量影响的同时开始性能调整之前，性能的影响并不重要

当您想要使用某个事物的多个实例时，可能会出现更严重的问题，然后您将不得不更改您的体系结构。我通常不是Singleton的朋友，只有当我100%确定我不可能需要第二个类实例时才会使用它们。
设计大型软件系统的一个重要部分是最小化组件和类之间的耦合。这可以通过封装不同组件的实现来实现。组件之间相互了解的越多，它们之间的依赖性就越高

使用单例模式意味着耦合到实现类（而不是接口或抽象）。最好是使用GameManager的每个组件都使用GameManagerInterface，这样就可以轻松地更改或扩展实现。隐藏对具体Singleton类的依赖是困难的，因为您必须在某个地方调用静态方法

...
IGameManager iGameManager = GameManager.getInstance();
...

使用这样的单例模式是…：

 GameManager.instance.someOtherClass.someVariable     

。。。这从来都不是个好主意。这样做会将调用类与每个被调用类的实现相耦合。最好只与你的直系邻居沟通，如“得墨忒尔定律”所说
（又称“告诉——不要问”或“不要和陌生人说话”）

也许您应该考虑一下单例模式的用途：单例模式用于确保一个类只有一个实例。没别的了

如前所述，在代码中的任何地方使用静态“getInstance”方法都会导致隐藏的依赖关系。您要做的是使用单例模式替换全局变量。这使系统变得脆弱，因为代码的每一部分都依赖于singleton类的实现。更改此类可能会使整个系统崩溃。
如果您经常使用单例模式，则不会有性能缺陷。从这个角度来看，你可以使用它多少次。
但是，如果你经常需要这个变量，你应该考虑重新设计。
如果需要全局变量，不要使用单例。使用单例的原因只有一个：“一个类不允许有多个实例。”

所以要注意这种模式。Janis在他的文章中很好地解释了这个问题。
答案很简单，即测量单态和非sigleton方法。在单例中，在堆上创建一个新对象；在非单例中，每次调用时都会创建一个新对象。
这是事实。虽然对我来说，当我使用一个单人游戏时，整个游戏/应用程序中只有一个单人游戏，而不是一个。我尽量不过度使用某些东西，并将我的东西分解成组件以便于扩展等等。如果是这样的话，就这样做吧。我99%确信这永远不会对你的表现产生可测量的影响。这通常来自图形操作和网络流量，可能是一些繁重的算法，如地形生成等。绝对不是来自访问单例。虽然它不是大型程序，但确实最好尽早学习。假设我有一个名为
Character
的类。这个character类想知道存储在Singleton中的一个细节，比如说
levelUpBoundary
，关于角色可以达到的高度。现在，我可以通过
GameManager.instance.levelUpBoundary
得到这个。您所说的是，我应该在
Character
脚本中创建一个变量，如下所示：
IGameManager IGameManager=GameManager.getInstance（）