游戏编程模式--单例模式

Posted 2021-02-11 xin-lover

单例模式

　　定义：确保一个类只有一个实例，并为其提供一个全局的访问入口。

　　那么什么情况下使用单例？最常见的情况就是一个类需要与一个维持自身状态的外部系统进行交互，比如说打印机。大多数情况下都是多人共用一个打印机，这意味着可能由多个人同时向这个打印机发送打印任务，这个时候管理打印机的类就必须熟悉打印机的当前状态并协调这些任务的执行。这个时候就不允许存在多个打印机的实例，因为实例无法知道其他的实例所做的操作，也就无法进行整体的管理。

　　我们先看看最常见的单例的实现方式：

class FileSystem
{
public:
    static FileSystem& instance_()
    {
        if(instance_ == nullptr)
        {
            instance_ = new FileSystem();
        }

        return instance_;
    }

private:
    FileSystem(){}
    static FileSystem* instance_;
};

　　c++11保证一个局部静态变量初始化只进行一次，哪怕实在多线程的情况下也是如此，所以c++11中这样写更优雅。

class FileSystem
{
public:
    static FileSystem& instance()
    {
        static FileSystem& instance_ = new FileSystem();

        return instance_;
    }

private:
    FileSystem(){}
};

特性

　　从代码实现上看，单例模式由以下几个特性：

• 　　如果我们不使用它，就不会创建实例。
• 　　它在运行时初始化。还有一种方法是使用静态类，但静态类有个局限就是：自动初始化。而且它是在main函数之前初始化，这也就意味了它不能使用运行时才能知道的信息，并且不能相互依赖——编译器并不能保证静态函数间初始化的顺序。
• 　　你可以继承单例，这可以让我们更好的控制我们的代码，比如对于多平台的文件系统，我们定义两个子类继承FileSystem的接口，通过一个编译指令控制文件系统类型的绑定，程序的其他代码可以与文件系统解耦（因为其他代码只是用FileSystem::instance())。

后悔使用单例模式的原因

　　（1）它是个全局变量

　　　根据前人的经验，全局变量时有害的，我们应该远离全局变量。为什么了？

• 它令代码晦涩难懂。本来在一个函数中，我们只需要关注函数段的局部代码即可，但如果在函数中使用了全局变量，则我们就需要追踪所有能改变全局变量状态的代码，如果这样的代码由成百上千行，你就会痛恨全局变量了。
• 全局变量促进了耦合。因为全局变量的特性，你只需要包含相应的头文件，就可以使用这个变量，这就增加了代码的耦合程度。
• 它对并发并不友好，这个显而易见。

　　（2）它是个画蛇添足的方案

　　　从定义上看出，单例模式其实是解决了两个问题：第一保证一个实例，第二提供已访问入口。保证一个单例是很有用的，但谁说我们希望谁都能操作它？而第二个问题，便利的访问通常是我们使用单例的主要原因。但这同时也会引出新的问题，比如一个日志类，一开始大家都使用这个单例的日志类时很方便，但随着项目的深入，对于日志的需求也复杂了起来，比如要求分类写入多个日志文件，这个时候因为你是单例，所以为了支持多个实例，你就要修改每个你调用这个类的地方，结果便利的访问也就不那么便利了。

　　（3）延迟初始化剥离了你的控制

　　　延迟初始化也就是在第一次调用的时候初始化，这样也就不能保证你初始化的时机。这通常在对性能要求非常高的游戏中时不被允许的，设想一个音频单例单例，初始化需要几百毫秒，而且伴随着内存的分配，如果你的游戏进行中突然调用这个单例，则会进行初始化操作，这件带来不可接受的游戏掉帧和卡顿。而且也不利于内存布局的控制。

　　在游戏中通常使用这样的方式来实现单例模式：

class FileSystem
{
public:
    static FileSystem& instance()
    {
        return instance_;
    }

private:
    FileSystem(){}
    static FileSystem instance_;
};

我们应该使用单例吗？

　　（1）首先看看你需不需类

　　在游戏中，我看见了太多的“manager”类了，它们的初衷时为了管理其它对象，虽然有时确实有用，但我更多的时看到它被滥用。比如下面的一个例子：

class Bullet
{
public:
    int getX() const {return x_;}
    int getY() const {return y_;}
    void setX(int x) {x_=x;}
    void setY(int y) {y_=y;}

private:
    int x_;
    int y_;
};

class BulletManager
{
public:
    Bullet* create(int x,int y)
    {
        Bullet* bullet = new Bullet();
        bullet->setX(x);
        bullet->setY(y);

        return bullet;
    }

    bool isOnScreen(Bullet& bullet)
    {
        return bullet.getX() >=0
            && bullet.getY >=0
            && bullet.getX() <= SCREEN_WIDTH
            && bullet.getY() <= SCREEN_HEIGHT;
    }

    void move(Bullet& bullet)
    {
        bullet.setX(bullet.getX() + 5);
    }
};

　　这个例子有点极端，但现实中很多manager类简化后就是这样的一个逻辑。我们通过一个单例来管理Bullet，感觉上好像合理，但仔细分析后，发现这个manager根本就没有存在的必要，设计出这样一个类的人应该对OOP不太熟悉。首先我们分析这三个方法：

1. 　　create创建一个Bullet，如果我们想要更好的管理Bullet的创建，那我们应该使用工厂模式，它会使我们的代码可维护性更高，或者直接在Bullet中提供一个静态函数来创建一个新的对象，从设计上来说更显得合理；
2. 　　isOnScreen判断是否在屏幕中，这个方法既可以放在业务层代码中也可以放入Bullet中（因为可以理解我为这是bullet的一个状态），把它放在这个Manager类中显得不伦不类；
3. 　　move是移动bullet，这个就好设计了，move本来就是bullet的行为，所以如果没有特别的需求，move应该放入Bullet类中。

　　所以，修改后，我们只需要一个Bullet类：

class Bullet
{
public:
    Bullet(int x,int y):x_(x),y_(y)
    {

    }

    bool isOnScreen()
    {
        return x_ >=0
            && y_ >=0
            && x_ <= SCREEN_WIDTH
            && y_ <= SCREEN_HEIGHT;
    }

    void move()
    {
        x_ += 5;
    }
};

　　这样修改后，类的设计显得更合理，更自然。我们完全不需要一个额外的manager单例来帮助我们管理，所以，在我们设计单例时，首先就要分析我们是否真的需要这个单例。

　　（2）将类限制为单一实例

　　我们使用单例模式，很多时候只是要限制该类只有一个实例，但这并不意味着我们要提供一个全局访问，我们可能只是想在某一部分代码中访问这个实例，这个时候如果使用单例模式提供一个全局的访问接口，将会削弱整体的框架。我们可以有几种方式避免这种情况的出现。比如：

class FileSystem
{
public:
    FileSystem()
    {
        assert(!instantiated);
        instantiated = true;
    }

    ~FileSystem()
    {
        instantiated = false;
    }

private:
    static bool instantiated;
};

bool FileSystem::instantiated = false;

　　通过一个断言，保证FileSystem只有一个实例。

　　（3）为实例提供便捷的访问方式

　　使用单例模式的另一个需求就是便利的访问，它能让我们随时随地的获取这个唯一的实例。但这与我们通用的编程准则不符，我们通常是在保证功能的情况下尽量限制变量使用的一个范围，这样我们就只需要记住它的地方机会少很多（想想全局变量带来的问题）。那在不适用单例模式的时候，我们还有什么其它的途径访问一个对象了？通常我们会有这么几种方式：

• 　　作为参数传递进去。这个是最简单，通常也是最好的方法。但有时我们会碰到这样的情况，即这个对象与函数的内容没什么必然的联系，比如我们执行一个渲染函数时要记录日志，如果把日志对象加入到函数的参数列表中，将会非常的奇怪，对于这种情况，我们需要一些其它的办法。
• 　　在基类中获取它。这需要设计一个良好的继承体系，既然所有的子类都要访问这个对象，我们可以把这个对象放到父类中让所有的子类都能访问到它。
• 　　使用其它全局对象访问它。现实中我们不太可能把所有的全局变量都移除，比如在大部分的游戏代码中我们都会定义一个代表整个游戏状态的Game或者World对象，我们可以把全局对象放入这些已有的全局变量中来减少它们的数量。
• 　　使用服务定位其来访问。这是一种专门设计一个类来给对象做全局访问的，将会在服务器定位模式一节讲解。

结语

　　所以，我们应该在什么时候使用单例了？老师说，单例并没有你想象的那样重要，如果你要确保类只被实例化一次，可以简单的使用一个静态类，如果还不满足要求，可以使用一个静态的标识符在运行时检查是否只有一个实例被创建。不过使用与否还是要视你自己需求来定，但一定要防止单例模式的滥用，这不会给你带来任何的好处。