游戏设计模式阅读笔记5——重访设计模式（单例模式）

目录

一、单例模式

保证一个类只有一个实例

提供访问该实例的全局访问点

二、优点

1.如果没人用，就不会创建实例。

2.它在运行时实例化。

3.可继承单例

三、缺点

1.它是全局变量

        i.理解代码更加困难（需要追踪整个代码库看什么修改了全局变量）

        ii.促进了耦合的发生。（容易被破坏结构）

        iii.对并行不友好。

2.惰性初始化的弊端

四、替代单例模式，给实例提供方便访问的方法

         1.传进来。

        2.从基类中获得

        3.从已是全局的东西中获取

         4.从服务定位器中获得

---

GOF描述的单例模式通常弊大于利。他们强调应该谨慎使用这个模式，但在游戏业界的口口相传中，这一提示经常被无视了。

一、单例模式

单例模式：保证一个类只有一个实例，并且提供了访问该实例的全局访问点。

保证一个类只有一个实例

只能有一个实例的情况，通常发生在类与保存全局状态的外部系统互动时。

不如封装文件的系统API类。因为操作需要一段时间完成，所以类使用异步操作。但是又要保证不会相互妨碍，所以只能有一个实例。

提供访问该实例的全局访问点

经典实现：

二、优点

1.如果没人用，就不会创建实例。

        单例只在第一次被请求时实例化，如果游戏永远不请求，那么它就不会被实例化。

2.它在运行时实例化。

         通常的替代方案是：使用含有静态成员变量的类。但静态成员有个限制：自动初始化。编译器在main()运行钱初始化静态变量。就不能用程序加载时的信息（比如：读取的配置表）。

        单例的惰性初始化，就可以解决这个问题。

3.可继承单例

        假设需要跨平台的文件系统封装类。为了达到这一点，需要它变成文件系统抽象出来的接，而子类为每个平台实现接口。

三、缺点

1.它是全局变量

        全局变量有害的原因：

        i.理解代码更加困难（需要追踪整个代码库看什么修改了全局变量）

        ii.促进了耦合的发生。（容易被破坏结构）

        iii.对并行不友好。

2.惰性初始化的弊端

四、替代单例模式，给实例提供方便访问的方法

         1.传进来。

                缩小对象范围，是最简单和最好的解决方法。

        2.从基类中获得

                很多游戏架构通常有浅层但是宽泛的继承层次，通常只有一层深。在深层定义，就保证了只有继承的类才能获得。

        3.从已是全局的东西中获取

        

         4.从服务定位器中获得