Service Locator模式想要解决的问题是解耦合服务提供者和用户,用户无需直接访问具体的服务提供者类。
比如发送短信/邮件,在应用程序的很多地方都会被使用,有两种简单的方法来实现:
SmsComponent::send(...)
SmsComponent::getInstance()->send(...)
前者使用了静态方法,后者使用单例模式。
但这两种情况,用户都必须直接访问SmsComponent这个具体的服务类,应用程序每个使用短信服务的地方都要这样做。
假如有一天你这个短信服务的实现发生了变化,比如被替换为一个新的Sms2Component,那么所有的代码必须被重构,
有些用户层面的代码还不能被直接访问,那么整个重构的成本就会更大。
解决这个问题的方法就是使用一个服务注册机制,每个服务提供者只需要在一个注册机那边注册自己的访问地址,
而无需告知所有人自己的“地址”,用户从注册机构那边查询到服务提供方然后按标准服务接口访问。
后面如果服务提供者的访问地址发生了变化,只需要更新注册机构那边的信息即可,而无需通知到所有用户。
按照上述模式,需要实现3个参与角色,
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);
}
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