服务定位器

服务定位器提供服务的全局接入点，避免使用者和实现服务的具体类耦合，解耦需要服务的代码和服务由谁提供以及服务在哪里。服务类定义了一堆操作的抽象接口，具体的服务提供者实现这个接口，分离的服务定位器提供了通过查询获取服务的方法，同时隐藏了服务提供者的具体细节和定位它的过程。

使用服务定位器的核心难点就是它将依赖-在两块代码之间的一点耦合-推迟到运行时再连接，这具有更大的灵活度，但是代价是更难在阅读代码时理解你依赖的是什么。

定位器是全局可访问的，任何代码都可以请求服务，这就意味着服务必须在任何环境下正确工作。如果你的类只期望在特定上下文中使用，避免模式将它暴露给整个世界更安全。

如果我们在服务提供者注册前使用服务，它会返回NULL，如果调用代码没有检查，程序就崩溃。通过空对象的设计模式可以解决该问题，当我们没有找到服务或程序没以正确的顺序调用时，不返回NULL，而是返回一个特定的，实现了请求对象一样接口的对象，它的实现什么也不做，保证代码就像收到了真的服务对象一样安全运行。

可以将服务定位器与装饰器模式相结合。

设计决策：
1.服务是如何被定位的？

a.外部代码注册，简单快捷，可以控制如何构建提供者，可以在游戏运行时改变服务，但是定位器依赖外部代码，一旦没有初始化或注册过服务，要么游戏崩溃要么就神秘不工作

b.使用预处理在编译时绑定，快速，保证服务可用，但是无法轻易改变服务

c.运行时设置，可以更换服务无需重新编译，同样的代码库可以支持多种设置（当目标是大杂烩半的移动设备是十分有用），需要创建设置系统，增加复杂性，加载服务需要时间。

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

a.把责任推回去，返回NULL。这意味着使用者必须处理失败，并决定如何处理失败

b.使用断言挂起程序，如果服务没有被找到，游戏停在试图使用它的后续代码之前。

c.返回空服务，使用者不必处理缺失的服务，当服务不可用，程序将继续。但这样较难查找无意缺失服务的漏洞

3.服务的服务范围有多大？

a.如果全局可访问：鼓励整个代码使用相同的服务，但全局变量使我们失去何时何地使用服务的控制权

b.如果接触被限制在某个类中：通过显示限制服务到继承树的一个分支上控制了耦合，可能导致重复的付出

如果服务局限于一个领域，那么限制它的服务范围在一个类上面，如果服务是广泛应用的，比如日志，那么就应该是全局的。