前语
不知道咱们在项目中有没有遇到过这样的场景，依据传入的类型，调用接口不同的完成类或许说服务，比方依据文件的类型运用 CSV解析器或许JSON解析器，在调用的客户端一般都是用if else去做判别，比方类型等于JSON，我就用JSON解析器，那假如新加一个类型的解析器，是不是调用的客户端还要修正呢？这明显太耦合了，本文就介绍一种办法，服务定位形式Service Locator Pattern来处理，它协助咱们消除紧耦合完成及其依靠性，并提出将服务与其具体类解耦。
欢迎关注个人大众号『JAVA旭阳』沟通沟通
一个例子入门
咱们经过一个例子来告知你怎么运用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 的文章总结了核心思想： “服务定位器背面的基本思想是具有一个知道怎么获取应用程序或许需求的所有服务的目标。因而，此应用程序的服务定位器将有一个在需求时返回“服务”的办法。”
Spring 的ServiceLocatorFactoryBean完成了 FactoryBean接口，创建了Service Factory服务工厂Bean。
总结
咱们经过运用服务定位器形式完成了一种扩展 Spring 操控反转的绝妙办法。它协助咱们处理了依靠注入未提供最佳处理方案的用例。也就是说，依靠注入仍然是首选，并且在大多数情况下不该运用服务定位器来替代依靠注入。
欢迎关注个人大众号『JAVA旭阳』沟通沟通
