设计模式篇：单例模式

在游戏开发中，我们常常会在一个或多个类中引用到另一个类的方法。而这种情况下，我们通常是希望引用到的这个类是同一个类，因为我们要保证数据的同步性和一致性。

因此，单例模式就应运而生了。

单例模式，保证一个类仅有一个实例，并提供一个访问它的全局访问点。

单例模式一般写法

    public class TestSingleton
    {
        private static TestSingleton instance;

        /// <summary>
        /// 防止类外用new进行实例化此类，而造成多个类的后果
        /// </summary>
        private TestSingleton()
        {
        }

        /// <summary>
        /// 唯一的全局访问点
        /// </summary>
        public static TestSingleton Instance
        {
            get
            {
                //如果实例不存在，则new一个新实例，否则返回已有实例
                return instance ?? (instance = new TestSingleton());
            }
        }
    }

单例模式在继承MonoBehaviour时的写法

前面那个例子很简单，可是当我们进行游戏开发的时候，往往情况比这复杂的多，比如我们为了调用Unity的API，必须要继承MonoBehaviour，而如果一个类继承了MonoBehaviour，他就不能通过new来创建实例，

必须

才行，

所以，索性我们直接把要形成单例的类挂载到游戏物体上，并编写如下代码编写单例

    public class TestSingleton:MonoBehaviour
    {
        private static TestSingleton instance;

        /// <summary>
        /// 防止类外用new进行实例化此类，而造成多个类的后果
        /// </summary>
        private TestSingleton()
        {
        }

        /// <summary>
        /// 唯一的全局访问点
        /// </summary>
        public static TestSingleton Instance
        {
            get
            {
                //
                if (instance == null)
                {
                    instance = FindObjectOfType<TestSingleton>();
                }

                return instance;
            }
        }
    }

使用单例模式的理由

单例模式因为Singleton类封装他唯一实例，这样他可以严格控制客户怎样访问以及何时访问它，简单的说就是对唯一实例的访问。

使用单例模式的场合

假如只是对某个类的字段或成员变量进行访问和更改，建议static，如果需要调用方法，那就做成单例。

思考：

单例模式是可以随意使用的吗？

并不是。

我们在开发中使用单例模式大多是想直接获取对象，而省略层次复杂的参数传递。可是，当此单例所担负的责任越来越大，项目就会原来越难以维护，其次，单例模式还违反了“开放——封闭”原则。因为，通过Instance获取的是“实现类”而不是“接口类”，即得到的为实体类，当设计需求改变或增加时，它将无法被代替。只能更改原有实现类里面的程序员，所以它不满足“对修改封闭”要求。

于是，以单例模式为基础，会有以下两种实现方式

• 子类向父类注册实体对象，让父类的Instance方法返回对象时，按条件查表返回对应的子类对象。
• 每个子类都实现单例模式，再由父类的Instance去获取这些子类