服务定位器模式（Service Locator Pattern）介绍
服务定位器模式（Service Locator Pattern）介绍
服务定位器模式
服务定位器模式（Service Locator Pattern）用在我们想使用 JNDI 查询定位各种服务的时候。考虑到为某个服务查找 JNDI 的代价很高，服务定位器模式充分利用了缓存技术。在首次请求某个服务时，服务定位器在 JNDI 中查找服务，并缓存该服务对象。当再次请求相同的服务时，服务定位器会在它的缓存中查找，这样可以在很大程度上提高应用程序的性能。以下是这种设计模式的实体。
- 服务（Service） - 实际处理请求的服务。对这种服务的引用可以在 JNDI 服务器中查找到。
- Context / 初始的 Context - JNDI Context 带有对要查找的服务的引用。
- 服务定位器（Service Locator） - 服务定位器是通过 JNDI 查找和缓存服务来获取服务的单点接触。
- 缓存（Cache） - 缓存存储服务的引用，以便复用它们。
- 客户端（Client） - Client 是通过 ServiceLocator 调用服务的对象。
实现
我们将创建 ServiceLocator、InitialContext、Cache、Service 作为表示实体的各种对象。Service1 和 Service2 表示实体服务。
ServiceLocatorPatternDemo，我们的演示类在这里是作为一个客户端，将使用 ServiceLocator 来演示服务定位器设计模式。
步骤 1
创建服务接口 Service。
Service.java
public interface Service {
public String getName();
public void execute();}步骤 2
创建实体服务。
Service1.java
public class Service1 implements Service {
public void execute(){
System.out.println("Executing Service1");
}
@Override
public String getName() {
return "Service1";
}}Service2.java
public class Service2 implements Service {
public void execute(){
System.out.println("Executing Service2");
}
@Override
public String getName() {
return "Service2";
}}步骤 3
为 JNDI 查询创建 InitialContext。
InitialContext.java
public class InitialContext {
public Object lookup(String jndiName){
if(jndiName.equalsIgnoreCase("SERVICE1")){
System.out.println("Looking up and creating a new Service1 object");
return new Service1();
}else if (jndiName.equalsIgnoreCase("SERVICE2")){
System.out.println("Looking up and creating a new Service2 object");
return new Service2();
}
return null; }}步骤 4
创建缓存 Cache。
Cache.java
import java.util.ArrayList;import java.util.List;public class Cache {
private List<Service> services;
public Cache(){
services = new ArrayList<Service>();
}
public Service getService(String serviceName){
for (Service service : services) {
if(service.getName().equalsIgnoreCase(serviceName)){
System.out.println("Returning cached "+serviceName+" object");
return service;
}
}
return null;
}
public void addService(Service newService){
boolean exists = false;
for (Service service : services) {
if(service.getName().equalsIgnoreCase(newService.getName())){
exists = true;
}
}
if(!exists){
services.add(newService);
}
}}步骤 5
创建服务定位器。
ServiceLocator.java
public class ServiceLocator {
private static Cache cache;
static {
cache = new Cache(); }
public static Service getService(String jndiName){
Service service = cache.getService(jndiName);
if(service != null){
return service;
}
InitialContext context = new InitialContext();
Service service1 = (Service)context.lookup(jndiName);
cache.addService(service1);
return service1;
}}步骤 6
使用 ServiceLocator 来演示服务定位器设计模式。
ServiceLocatorPatternDemo.java
public class ServiceLocatorPatternDemo {
public static void main(String[] args) {
Service service = ServiceLocator.getService("Service1");
service.execute();
service = ServiceLocator.getService("Service2");
service.execute();
service = ServiceLocator.getService("Service1");
service.execute();
service = ServiceLocator.getService("Service2");
service.execute(); }}步骤 7
验证输出。
Looking up and creating a new Service1 objectExecuting Service1Looking up and creating a new Service2 objectExecuting Service2Returning cached Service1 objectExecuting Service1Returning cached Service2 objectExecuting Service2模式所要解决的问题
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
腾讯云开发者
