单例模式简述


“确保一个类只有一个实例,并为其提供一个全局访问入口”。
单例模式不仅描述非常简单,代码也非常好写,类似这样:

class Singleton {
public:
    static public Singleton* getInstance(){
        if (instance == NULL){
            instance = new Singleton();
        }
        return instance;
    }
private:
    Singleton(){}
    static Singleton* instance;
}

单例模式确实带给了我们极大的方便,有些情况下,一个类有多个实例就不能正常工作。
比如一个操作文件的类,为了保证各步操作不互相干扰,我们封装的类就必须知道每步调用的操作,如果这个类有多个实例,那么我们就无法获知其他实例的操作。

被玩坏的单例


现在,我学会了一个很好的模式,我一定要在实际编程中使用它~
然后,灾难就来了:我需要一个XXX管理器,在游戏的很多地方都要使用它,对了,使用单例模式就轻松解决了!
于是,在代码中就充满了单例,然而,单例一时爽,却有很多隐患。

虽然有单例模式这种看起来高端一些的名字,实际上,单例模式就是一个全局变量,全局变量的危害许多人都非常了解,但是套上了一层设计模式的面纱,就把它抛之脑后了,美其名曰:我再使用单例模式写代码。但是,随着游戏变得更大更复杂,这样的全局变量就会带来很多危害:

  1. 它们令代码晦涩难懂。假设我们正在跟踪其他人写的函数中的bug。如果这个函数没有使用全局状态,那么我们只需要将精力集中在理解函数体,和传递给它的参数就可以了。
  1. 全局变量促进了耦合。全局变量使得任何人都可以轻松的使用它,在一个不了解结构的新手完成开发任务时,很可能为了完成任务,使得本不应该产生耦合的地方使用了这个单例。
  2. 它对并发不友好。当设置全局变量时,我们创建了一段内存,每个线程都能访问和修改它,而不管它们是否知道其他线程正在操作它。这有可能导致死锁、条件竞争和其他一些难以修复的线程同步的bug。

难以控制的单例


如果你的单例会在需要的时候创建,会出现这样的问题:你无法得知单例创建的时间。

当你实例化一个游戏系统的时候,可能会花费较长的时间,作为用户,肯定不希望在玩游戏玩得正嗨的时候遇到卡顿和掉帧,因此,比较好的方法是在加载游戏的时候手动控制单例的初始化。

你还需要小心翼翼的处理单例初始化的顺序(如果某个单例与另一个单例存在耦合,当然,不存在耦合是最好的,然而,当系统非常庞大的时候,你很难保证这一点),让你的系统能够正常的运行。

LZ在做的游戏中有个读取配置的单例系统,在做另一个单例系统的功能的时候,又依赖这个读取配置的单例。悲剧的是,在退出游戏到登录界面的时候,会把原来的系统干掉,重新读取配置,然而,另一个单例却依然存在,在某些特殊的情况下,调用这个功能的时候,程序就会崩溃掉。
因此,LZ不得不将两个系统的生命周期理顺,在当时临近发版本不能发生大的改动的情况下,只能加上很多check的代码防止崩溃。
虽然这个例子中的情况并不会很常见,但LZ想说的是,这个系统本来就可以不用单例的方式编写,当你能很好的控制这个实例的生命周期的时候,以上出现的各种奇怪的问题就不会出现了。单例用起来简单,可是它会一步一步将你的系统变得更见复杂和难以管理,留下许多暗坑。因此,在你想使用单例的时候,最好想一想,是否一定需要这样处理。

Other


当然,完全不使用单例也不是很现实。单例依然很强大并实用,在使用中,始终保持谨慎是很重要的,在最需要的地方使用,而抛弃那些可有可无的方案,不让单例模式在代码中泛滥,会让程序更加健壮~

文章来源于互联网:游戏编程模式|不要让单例在代码中泛滥

发表评论