游戏设计模式阅读笔记15——解耦模式（服务定位器）

    

目录

一、动机

二、服务定位器详解

1.适用情况：

2.实例代码

3.服务如何被定位

4.如果服务不能被定位怎么办

---

    

        提供服务的全局接入点，避免使用者和实现服务的具体类耦合。

一、动机

        游戏中有很共用的功能，很多系统都会涉及一些。比如内存分配，记录日志，或者随机数字。以音频为例，当我们需要播放音频时，直接接触到具体的音频实现。当我们的音频函数修改的时候，所有调用了这个函数的地方都需要我们去修改。

更好的解决就是，有一个查询的地方，然后别的系统在这里找到音频。这样如果音频修改了，也只需要在中间商这里修改。

         所以服务器模式就用来解耦需要服务的代码和服务由谁提供以及服务在哪里。

二、服务定位器详解

        服务类定义了一堆操作的抽象接口。具体的服务提供者实现这个接口。分离的服务定位器提供了通过查询获取服务方法，同时隐藏了服务提供者的具体细节和定位它的过程。

1.适用情况：

         就像单例模式一样，这个模式是全局的。应该尽量少用。优先考虑将服务者传给代码。但当只有一个系统，且需要传过很多函数才能被需要者调用时，就可以使用这个模式。

        因为定位器是全局可访问的，所以应该保证里面的服务在任何环境下都能正常工作。如果只是给特定的部分使用，就不适合作为服务。

2.实例代码

        一个简单的定位器：静态函数getAudio()完成了定位工作。

        这里可以结合另一个设计模式“空对象”一起使用，实现一个空对象类，实现了这些虚函数只是没有操作。避免当没有服务者时，请求的人获取错误导致游戏崩溃。

        

3.服务如何被定位

1.外部代码注册

        1.getAudio()函数简单地返回指针。简单快捷。

        2.可以控制如何构建提供者

        3.可以在游戏运行时改变服务

        4.定位器依赖外部代码

2.在编译时绑定

        1.快速

        2.能保证服务可用

        3.无法轻易改变服务

3.在运行时设置

        这就意味着需要加载设置文件确认提供者，然后使用反射在运行时实例化这个类。

        1.可以更换服务无需重新编译

        2.非程序员也可以改变服务

        3.同样的代码库可以同时支持多种设置

        4.复杂

        5.加载服务需要时间

4.如果服务不能被定位怎么办

        1.让使用者自己处理

        2.挂起游戏

        3.返回空服务