Spring项目中应用服务定位模式
不知道大家在项目中有没有遇到过这样的场景,根据传入的类型,调用接口不同的实现类或者说服务,比如根据文件的类型使用 CSV解析器或者JSON解析器,在调用的客户端一般都是用if else
去做判断,比如类型等于JSON,我就用JSON解析器,那如果新加一个类型的解析器,是不是调用的客户端还要修改呢?这显然太耦合了,本文就介绍一种方法,服务定位模式Service Locator Pattern
来解决,它帮助我们消除紧耦合实现及其依赖性,并提出将服务与其具体类解耦。
文件解析器的例子
我们通过一个例子来告诉你如何使用Service Locator Pattern
。
假设我们有一个从各种来源获取数据的应用程序,我们必须解析不同类型的文件,比如解析CSV文件和JSON文件。
1、定义一个类型的枚举
public enum ContentType { JSON, CSV }
2、定义一个解析的接口
public interface Parser { List parse(Reader r); }
3、根据不同的文件类型有不同的实现类
// 解析csv @Component public class CSVParser implements Parser { @Override public List parse(Reader r) { .. } } // 解析json @Component public class JSONParser implements Parser { @Override public List parse(Reader r) { .. } }
4、最后写一个调用的客户端,通过switch case
根据不同的类型调用不同的实现
@Service public class Client { private Parser csvParser, jsonParser; @Autowired public Client(Parser csvParser, Parser jsonParser) { this.csvParser = csvParser; this.jsonParser = jsonParser; } public List getAll(ContentType contentType) { .. switch (contentType) { case CSV: return csvParser.parse(reader); case JSON: return jsonParser.parse(reader); .. } } .. }
可能大部分人都是像上面一样的方式实现的,也能正常运行,那深入思考下,存在什么问题吗?
现在假如产品经理提出了一个新需求要支持XML类型的文件,是不是客户端也要修改代码,需要在switch case
中添加新的类型,这就导致客户端和不同的解析器紧密耦合。
那么有什么更好的方法呢?
应用Service Locator Pattern
没错,那就是用上我们的服务定位模式Service Locator Pattern
。
1、让我们定义我们的服务定位器接口ParserFactory
, 它有一个接受内容类型参数并返回Parser
的方法。
public interface ParserFactory { Parser getParser(ContentType contentType); }
2、我们配置ServiceLocatorFactoryBean
使用ParserFactory
作为服务定位器接口,ParserFactory
这个接口不需要写实现类。
@Configuration public class ParserConfig { @Bean("parserFactory") public FactoryBean serviceLocatorFactoryBean() { ServiceLocatorFactoryBean factoryBean = new ServiceLocatorFactoryBean(); // 设置服务定位接口 factoryBean.setServiceLocatorInterface(ParserFactory.class); return factoryBean; } }
3、设置解析器Bean的名称为类型名称,方便服务定位
// 设置bean的名称和类型一致 @Component("CSV") public class CSVParser implements Parser { .. } @Component("JSON") public class JSONParser implements Parser { .. } @Component("XML") public class XMLParser implements Parser { .. }
4、修改枚举, 添加XML
public enum ContentType { JSON, CSV, XML }
5、最后用客户端调用,直接根据类型调用对应的解析器,没有了switch case
@Service public class Client { private ParserFactory parserFactory; @Autowired public Client(ParserFactory parserFactory) { this.parserFactory = parserFactory; } public List getAll(ContentType contentType) { .. // 关键点,直接根据类型获取 return parserFactory .getParser(contentType) .parse(reader); } .. }
嘿嘿,我们已经成功地实现了我们的目标。现在再加新的类型,我们只要扩展添加新的解析器就行,再也不用修改客户端了,满足开闭原则。
如果你觉得Bean的名称直接使用类型怪怪的,这边可以建议你按照下面的方式来。
public enum ContentType { JSON(TypeConstants.JSON_PARSER), CSV(TypeConstants.CSV_PARSER), XML(TypeConstants.XML_PARSER); private final String parserName; ContentType(String parserName) { this.parserName = parserName; } @Override public String toString() { return this.parserName; } public interface TypeConstants { String CSV_PARSER = "csvParser"; String JSON_PARSER = "jsonParser"; String XML_PARSER = "xmlParser"; } } @Component(TypeConstants.CSV_PARSER) public class CSVParser implements Parser { .. } @Component(TypeConstants.JSON_PARSER) public class JSONParser implements Parser { .. } @Component(TypeConstants.XML_PARSER) public class XMLParser implements Parser { .. }
剖析Service Locator Pattern
通过前面的例子,想必大家基本知道服务定位器模式如何使用了吧,现在我们深入剖析下。
服务定位器模式消除了客户端对具体实现的依赖。以下引自 Martin Fowler
的文章总结了核心思想:“服务定位器背后的基本思想是拥有一个知道如何获取应用程序可能需要的所有服务的对象。因此,此应用程序的服务定位器将有一个在需要时返回“服务”的方法。”
Spring
的ServiceLocatorFactoryBean
实现了 FactoryBean
接口,创建了Service Factory
服务工厂Bean
。
总结
我们通过使用服务定位器模式实现了一种扩展 Spring 控制反转的绝妙方法。它帮助我们解决了依赖注入未提供最佳解决方案的用例。也就是说,依赖注入仍然是首选,并且在大多数情况下不应使用服务定位器来替代依赖注入。
参考文章:
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 地球OL攻略 —— 某应届生求职总结
· 提示词工程——AI应用必不可少的技术
· Open-Sora 2.0 重磅开源!
· 周边上新:园子的第一款马克杯温暖上架