使用设计模式的好处（简单列举）

        1. 解决共通的问题：每种设计模式都对应着一种思路，可以理解为解决每一类问题。

        2.归纳相同的解决方案：一种设计模式可以解决的问题都有共同的点，归纳解决

        3.类结构和组装方式：为了让开发更加轻松和代码更容易复用，游戏上线之后更好维护

        4.高复用度和组合使用：很多设计模式都是通用解决方案，用上设计模式的代码有时候不仅仅只在一个项目可以使用，体现了高复用度从而减少工作量。组合使用则是多个设计模式可以组合使用，构成一个功能性完善、质量高的框架。

一、单例模式

        一般来说，在游戏开发里具有唯一性（必须、使用场景）的类并且直到游戏结束才需要销毁的时候、比如音效管理类、游戏管理类，这种类只有一个，我们又要经常使用他，每一个脚本使用他的时候就要new他，能不能有一种方法让我们不new他也能使用呢？反正他只有一个，这时候单例模式就可以很好的解决这个问题了。单例的优点有同时间只存在一个对象、快速获取对象的方法、适合游戏单一功能的管理器等

        1.1普通单例

        普通单例先说第一种缺点很明显的，直接在Awake单例，缺点就是有很多个脚本的时候不知道哪个Awake先运行，假定另外一个单例也在Awake执行，如果此时去做初始化工作调用另一个单例的时候，那个脚本的Awake又还没执行导致另一个单例为空，故不推荐这样使用。

public class GameManager: MonoBehaviour
{
    public static GameManager instance;

    private void Awake()
    {
        instance = this;
    }

}

         推荐使用：改善方式，写一个属性，调用的时候就不用担心生命周期的问题了，当然除了去Find也可以new一个Gameobject出来。

public class GameManager : MonoBehaviour
{
    private static GameManager instance;

    public static GameManager Instance
    {
        get
        {
            if (instance == null)
            {
                //一般脚本都会挂载在物体上
                //个人习惯直接FindObjectOfType防止空指针
                instance = FindObjectOfType<GameManager>();
            }
            return instance;
        }
    }

}

        1.2单例基类

        项目很多个类都需要变成单例的时候，一个一个的写单例就浪费了我们的时间，为了代码更优雅、为了面向对象的继承思想、为了提高复用性、为了........偷懒，就写一个泛型的单例基类来使用，为了保险起见把new GameObject()也上了，要用的时候填上泛型直接继承就行了。

public class GetInstance<T> : MonoBehaviour where T :MonoBehaviour
{
    private static T instance;
    public static T Instance()
    {
        if (instance = null)
        {
            instance = FindObjectOfType(typeof(T)) as T;
            if (instance == null)
            {
                GameObject obj = new GameObject();
                obj.name = typeof(T).ToString();
                DontDestroyOnLoad(obj);
                instance = obj.AddComponent<T>();
            }
        }
        return instance;
    }
}