Unity中 单例模式
单例模式
1.静态方法访问
在Unity中，"单例模式"（Singleton Pattern）是一种常见的软件设计模式。它用于确保一个类只有一个唯一的实例，并提供一种全局访问点，使得其他类可以轻松地访问该唯一实例。
在游戏开发中，特别是使用Unity引擎时，单例模式经常用于管理全局的状态、资源、设置或其他对象，以确保它们在整个游戏中始终只存在一个实例，从而避免不必要的重复创建和管理实例。
实现一个Unity单例模式通常涉及以下几个步骤：
1. 私有构造函数：为了防止在类外部创建新的实例，将构造函数设为私有，这样其他类就不能直接通过 new 关键字来实例化该类。
2. 静态实例变量：在类内部创建一个静态（static）的类实例变量，这将是该类的唯一实例。
3. 静态访问方法：提供一个静态方法（通常命名为 GetInstance() 或 Instance() 等），使得其他类可以通过调用这个方法来获取该类的唯一实例。
4. 确保唯一性：在静态访问方法中，确保只有一个实例被创建。如果实例还不存在，则在方法内部创建一个新实例并返回；如果实例已经存在，则直接返回已有的实例。
下面是一个简单的Unity C#脚本示例，展示了如何实现一个基本的单例模式：
public class MySingleton : MonoBehaviour
{
private static MySingleton instance;
// 私有构造函数
private MySingleton() { }
// 静态访问方法
public static MySingleton GetInstance()
{
if (instance == null)
{
instance = new GameObject("MySingleton").AddComponent();
}
return instance;
}
// 可选：添加其他功能和数据到这个单例类
} 在上面的例子中， MySingleton 类的构造函数被设置为私有，只能在类的内部访问。通过 GetInstance() 方法，其他类可以获取到 MySingleton 类的唯一实例。如果该实例不存在，它将在内部被创建，否则直接返回已有的实例。
请注意，尽管单例模式在某些情况下很有用，但过度使用它可能会导致代码难以维护和测试。在使用单例模式时，应该谨慎考虑其实际需求，避免过度使用全局状态。
2.静态字段访问
如果我们想直接使用 instance 这个变量，我们可以将 instance 定义为公共字段而不是属性。这样，在其他脚本中就可以直接通过 GameManager.instance 来访问它。
public class GameManager : MonoBehaviour
{
public static GameManager instance;
private void Awake()
{
if(instance!=null)
{
Destroy(gameObject);
}
else
{
instance = this;
DontDestroyOnLoad(gameObject);
}
}
public void Walk()
{
// 实现 Walk 方法的代码
}
}在上面的例子中， GameManager 类的 instance 字段被定义为公共静态。在 Awake() 方法中，如果 instance 为 null ，则将当前实例赋值给 instance ，否则销毁重复的实例。这样，我们就可以在其他脚本中通过 GameManager.instance 来访问 GameManager 的唯一实例。
在其他脚本中，我们可以这样使用：
GameManager.instance.Walk();
这样就可以直接调用 Walk() 方法而无需加括号。请注意，使用这种方式时，确保在调用 GameManager.instance 之前， GameManager 类的实例已经被正确初始化。
3.两种方法比较
两种方法各有优缺点，取决于我们的需求和项目的规模。让我们来比较一下：
（1）使用静态方法：
优点：
易于理解和维护：使用 GetInstance() 等明确的静态方法，可以清楚地表明我们正在获取单例实例。
更好的封装：通过静态方法，可以对实例创建的逻辑进行更好的封装，确保在获取实例时进行一些初始化或其他操作。
更安全：可以更好地控制实例的创建过程，避免因不当的直接访问导致的意外行为。
缺点：
冗余代码：在使用单例的时候，可能需要多次写 GetInstance() 方法调用，造成一定程度的代码冗余。
（2）使用公共静态字段：
优点：
简洁：直接使用 GameManager.instance 来访问单例实例，代码更加简洁明了。
减少方法调用：省略了调用静态方法的过程，直接使用字段访问。
缺点：
可读性和维护性较差：在代码中，我们无法清楚地看出 instance 是来自单例模式的，初次阅读代码可能会不太容易理解。
可能不够安全：由于没有封装的控制，其他代码可能会直接修改或重置 instance ，可能导致单例实例状态的不稳定。
综上所述，如果我们更关注代码的可读性、维护性和安全性，推荐使用静态方法来获取单例实例。这种方式使代码更具意图，并且允许在获取实例时进行更好的封装和控制。
如果我们更看重代码的简洁性，并且确认在项目中不会出现意外的直接修改 instance 的情况，使用公共静态字段可能会更加方便。
不管选择哪种方式，确保单例的创建和初始化逻辑是正确的，并且在使用单例实例时要小心避免潜在的错误和异常。