Spring项目中用了这种模式，经理对我刮目相看

不知道大家在项目中有没有遇到过这样的场景，根据传入的类型，调用接口不同的实现类或者说服务，比如根据文件的类型使用 CSV解析器或者JSON解析器，在调用的客户端一般都是用if else​去做判断，比如类型等于JSON，我就用JSON解析器，那如果新加一个类型的解析器，是不是调用的客户端还要修改呢？这显然太耦合了，本文就介绍一种方法，服务定位模式Service Locator Pattern来解决，它帮助我们消除紧耦合实现及其依赖性，并提出将服务与其具体类解耦。,我们通过一个例子来告诉你如何使用Service Locator Pattern。,假设我们有一个从各种来源获取数据的应用程序，我们必须解析不同类型的文件，比如解析CSV文件和JSON文件。,可能大部分人都是像上面一样的方式实现的，也能正常运行，那深入思考下，存在什么问题吗？,现在假如产品经理提出了一个新需求要支持XML类型的文件，是不是客户端也要修改代码，需要在switch case中添加新的类型，这就导致客户端和不同的解析器紧密耦合。,那么有什么更好的方法呢？,没错，那就是用上我们的服务定位模式Service Locator Pattern。,嘿嘿，我们已经成功地实现了我们的目标。现在再加新的类型，我们只要扩展添加新的解析器就行，再也不用修改客户端了，满足开闭原则。,如果你觉得Bean的名称直接使用类型怪怪的，这边可以建议你按照下面的方式来。,通过前面的例子，想必大家基本知道服务定位器模式如何使用了吧，现在我们深入剖析下。,服务定位器模式消除了客户端对具体实现的依赖。以下引自 Martin Fowler 的文章总结了核心思想：“服务定位器背后的基本思想是拥有一个知道如何获取应用程序可能需要的所有服务的对象。因此，此应用程序的服务定位器将有一个在需要时返回“服务”的方法。”,,Spring​ 的ServiceLocatorFactoryBean​实现了 FactoryBean​接口，创建了Service Factory​服务工厂Bean。,我们通过使用服务定位器模式实现了一种扩展 Spring 控制反转的绝妙方法。它帮助我们解决了依赖注入未提供最佳解决方案的用例。也就是说，依赖注入仍然是首选，并且在大多数情况下不应使用服务定位器来替代依赖注入。