文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Spring你不知道的一种解耦模式

2023-01-28 06:05

关注

前言

不知道大家在项目中有没有遇到过这样的场景,根据传入的类型,调用接口不同的实现类或者说服务,比如根据文件的类型使用 CSV解析器或者JSON解析器,在调用的客户端一般都是用if else去做判断,比如类型等于JSON,我就用JSON解析器,那如果新加一个类型的解析器,是不是调用的客户端还要修改呢?这显然太耦合了,本文就介绍一种方法,服务定位模式Service Locator Pattern来解决,它帮助我们消除紧耦合实现及其依赖性,并提出将服务与其具体类解耦。

一个例子入门

我们通过一个例子来告诉你如何使用Service Locator Pattern

假设我们有一个从各种来源获取数据的应用程序,我们必须解析不同类型的文件,比如解析CSV文件和JSON文件。

定义一个类型的枚举

public enum ContentType {
  JSON,
  CSV
}

定义一个解析的接口

public interface Parser {
  List parse(Reader r);
}

根据不同的文件类型有不同的实现类

// 解析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) { .. }
}

最后写一个调用的客户端,通过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

让我们定义我们的服务定 位器接口ParserFactory, 它有一个接受内容类型参数并返回Parser的方法。

public interface ParserFactory {
  Parser getParser(ContentType contentType);
}

我们配置ServiceLocatorFactoryBean使用ParserFactory作为服务定 位器接口,ParserFactory这个接口不需要写实现类。

@Configuration
public class ParserConfig {
  @Bean("parserFactory")
  public FactoryBean serviceLocatorFactoryBean() {
    ServiceLocatorFactoryBean factoryBean = new ServiceLocatorFactoryBean();
    // 设置服务定位接口   
    factoryBean.setServiceLocatorInterface(ParserFactory.class);
    return factoryBean;
  }
}

设置解析器Bean的名称为类型名称,方便服务定位

// 设置bean的名称和类型一致
@Component("CSV")
public class CSVParser implements Parser { .. }
@Component("JSON")
public class JSONParser implements Parser { .. }
@Component("XML")
public class XMLParser implements Parser { .. }

修改枚举, 添加XML

public enum ContentType {
  JSON,
  CSV,
  XML
}

最后用客户端调用,直接根据类型调用对应的解析器,没有了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 的文章总结了核心思想: “服务定 位器背后的基本思想是拥有一个知道如何获取应用程序可能需要的所有服务的对象。因此,此应用程序的服务定 位器将有一个在需要时返回“服务”的方法。”

SpringServiceLocatorFactoryBean实现了 FactoryBean接口,创建了Service Factory服务工厂Bean

总结

我们通过使用服务定 位器模式实现了一种扩展 Spring 控制反转的绝妙方法。它帮助我们解决了依赖注入未提供最佳解决方案的用例。也就是说,依赖注入仍然是首选,并且在大多数情况下不应使用服务定 位器来替代依赖注入。

到此这篇关于Spring你不知道的一种解耦模式的文章就介绍到这了,更多相关Spring解耦模式内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网!

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯