服务定位器模式（Service Locator Pattern）详解和代码示范

模式所要解决的问题

Service Locator模式想要解决的问题是解耦合服务提供者和用户，用户无需直接访问具体的服务提供者类。

比如发送短信/邮件，在应用程序的很多地方都会被使用，有两种简单的方法来实现：

SmsComponent::send(...)

SmsComponent::getInstance()->send(...)

前者使用了静态方法，后者使用单例模式。

但这两种情况，用户都必须直接访问SmsComponent这个具体的服务类，应用程序每个使用短信服务的地方都要这样做。

假如有一天你这个短信服务的实现发生了变化，比如被替换为一个新的Sms2Component，那么所有的代码必须被重构，

有些用户层面的代码还不能被直接访问，那么整个重构的成本就会更大。

解决方法和代码示范

解决这个问题的方法就是使用一个服务注册机制，每个服务提供者只需要在一个注册机那边注册自己的访问地址，

而无需告知所有人自己的“地址”，用户从注册机构那边查询到服务提供方然后按标准服务接口访问。

后面如果服务提供者的访问地址发生了变化，只需要更新注册机构那边的信息即可，而无需通知到所有用户。

按照上述模式，需要实现3个参与角色，

首先设计实现一个服务提供者，接口为ISms：

class SmsComponent : public ISms
{
public:
  virtual void send(...)
  {
  }
};

接着实现注册机（定位器），

class Locator
{
public:
  static ISms* getSms() { return _service; }

  static void register(IAudio* service)
  {
    _service = service;
  }

private:
  static IAudio* _service;
};

然后在程序入口处注册这个服务：

void initApp()
{
  SmsComponent *sms = new SmsComponent();
  Locator::register(sms);
}

然后用户可以使用getSms方法来调用这个服务，

void someCode()
{
  ISms *sms = Locator::getSms();
  sms->send('hey there',...);
}

服务定位器模式的优缺点

服务定位器模式在带来解耦和、可维护性、动态升级服务等好处的同时，也带来一些不好的方面，比如

1、由于用户无法确切知道服务提供者的真实情况，那么如果出现错误，难以定位

2、集中式、单例的注册机是并行计算、系统扩展的瓶颈

3、由于需要集成全局的服务注册代码，执行单元测试也会麻烦些

4、注册机隐藏了类的依赖关系，使得本来在编译期可以暴露的问题，在运行时才发生

当然服务定位器模式针对具体情况和上述问题，也有一些变通/折中的模式，比如为了解决问题4，

可以把具体的服务类声明在定位器的成员变量中，省略注册过程，让定位器直接拥有具体的服务类：

class Locator
{
public:
  static ISms* getSms() { return _service; }

private:
  static SmsComponent _service;
};

当然这样就失去了动态选择服务的好处，每次变更短信服务，必须要重新编译。

参考链接：

http://www.oracle.com/technetwork/java/servicelocator-137181.html

http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/

http://gameprogrammingpatterns.com/service-locator.html

by iefreer