來源：JAVA旭陽

不知道大家在項目中有沒有遇到過這樣的場景，根據(jù)傳入的類型，調(diào)用接口不同的實現(xiàn)類或者說服務(wù)，比如根據(jù)文件的類型使用 CSV解析器或者JSON解析器，在調(diào)用的客戶端一般都是用if else去做判斷，比如類型等于JSON，我就用JSON解析器，那如果新加一個類型的解析器，是不是調(diào)用的客戶端還要修改呢？這顯然太耦合了，本文就介紹一種方法，服務(wù)定位模式Service Locator Pattern來解決，它幫助我們消除緊耦合實現(xiàn)及其依賴性，并提出將服務(wù)與其具體類解耦。

文件解析器的例子

我們通過一個例子來告訴你如何使用Service Locator Pattern。

假設(shè)我們有一個從各種來源獲取數(shù)據(jù)的應(yīng)用程序，我們必須解析不同類型的文件，比如解析CSV文件和JSON文件。

1、定義一個類型的枚舉

publicenumContentType{
JSON,
CSV
}

2、定義一個解析的接口

publicinterfaceParser{
Listparse(Readerr);
}

3、根據(jù)不同的文件類型有不同的實現(xiàn)類

//解析csv
@Component
publicclassCSVParserimplementsParser{
@Override
publicListparse(Readerr){..}
}

//解析json
@Component
publicclassJSONParserimplementsParser{
@Override
publicListparse(Readerr){..}
}

4、最后寫一個調(diào)用的客戶端，通過switch case根據(jù)不同的類型調(diào)用不同的實現(xiàn)

@Service
publicclassClient{
privateParsercsvParser,jsonParser;

@Autowired
publicClient(ParsercsvParser,ParserjsonParser){
this.csvParser=csvParser;
this.jsonParser=jsonParser;
}

publicListgetAll(ContentTypecontentType){
..

switch(contentType){
caseCSV:
returncsvParser.parse(reader);
caseJSON:
returnjsonParser.parse(reader);
..
}
}
..
}

可能大部分人都是像上面一樣的方式實現(xiàn)的，也能正常運行，那深入思考下，存在什么問題嗎？

現(xiàn)在假如產(chǎn)品經(jīng)理提出了一個新需求要支持XML類型的文件，是不是客戶端也要修改代碼，需要在switch case中添加新的類型，這就導致客戶端和不同的解析器緊密耦合。

那么有什么更好的方法呢？

應(yīng)用Service Locator Pattern

沒錯，那就是用上我們的服務(wù)定位模式Service Locator Pattern。

1、讓我們定義我們的服務(wù)定位器接口ParserFactory， 它有一個接受內(nèi)容類型參數(shù)并返回Parser的方法。

publicinterfaceParserFactory{
ParsergetParser(ContentTypecontentType);
}

2、我們配置ServiceLocatorFactoryBean使用ParserFactory作為服務(wù)定位器接口，ParserFactory這個接口不需要寫實現(xiàn)類。

@Configuration
publicclassParserConfig{

@Bean("parserFactory")
publicFactoryBeanserviceLocatorFactoryBean(){
ServiceLocatorFactoryBeanfactoryBean=newServiceLocatorFactoryBean();
//設(shè)置服務(wù)定位接口
factoryBean.setServiceLocatorInterface(ParserFactory.class);
returnfactoryBean;
}

}

3、設(shè)置解析器Bean的名稱為類型名稱，方便服務(wù)定位

//設(shè)置bean的名稱和類型一致
@Component("CSV")
publicclassCSVParserimplementsParser{..}
@Component("JSON")
publicclassJSONParserimplementsParser{..}
@Component("XML")
publicclassXMLParserimplementsParser{..}

4、修改枚舉, 添加XML

publicenumContentType{
JSON,
CSV,
XML
}

5、最后用客戶端調(diào)用，直接根據(jù)類型調(diào)用對應(yīng)的解析器，沒有了switch case

@Service
publicclassClient{
privateParserFactoryparserFactory;
@Autowired
publicClient(ParserFactoryparserFactory){
this.parserFactory=parserFactory;
}
publicListgetAll(ContentTypecontentType){
..
//關(guān)鍵點，直接根據(jù)類型獲取
returnparserFactory
.getParser(contentType)
.parse(reader);
}
..
}

嘿嘿，我們已經(jīng)成功地實現(xiàn)了我們的目標?，F(xiàn)在再加新的類型，我們只要擴展添加新的解析器就行，再也不用修改客戶端了，滿足開閉原則。

如果你覺得Bean的名稱直接使用類型怪怪的，這邊可以建議你按照下面的方式來。

publicenumContentType{
JSON(TypeConstants.JSON_PARSER),
CSV(TypeConstants.CSV_PARSER),
XML(TypeConstants.XML_PARSER);
privatefinalStringparserName;
ContentType(StringparserName){
this.parserName=parserName;
}

@Override
publicStringtoString(){
returnthis.parserName;
}
publicinterfaceTypeConstants{

StringCSV_PARSER="csvParser";
StringJSON_PARSER="jsonParser";
StringXML_PARSER="xmlParser";
}
}

@Component(TypeConstants.CSV_PARSER)
publicclassCSVParserimplementsParser{..}
@Component(TypeConstants.JSON_PARSER)
publicclassJSONParserimplementsParser{..}
@Component(TypeConstants.XML_PARSER)
publicclassXMLParserimplementsParser{..}

剖析Service Locator Pattern

通過前面的例子，想必大家基本知道服務(wù)定位器模式如何使用了吧，現(xiàn)在我們深入剖析下。

服務(wù)定位器模式消除了客戶端對具體實現(xiàn)的依賴。以下引自Martin Fowler的文章總結(jié)了核心思想：“服務(wù)定位器背后的基本思想是擁有一個知道如何獲取應(yīng)用程序可能需要的所有服務(wù)的對象。因此，此應(yīng)用程序的服務(wù)定位器將有一個在需要時返回“服務(wù)”的方法?！?/p>

Spring的ServiceLocatorFactoryBean實現(xiàn)了FactoryBean接口，創(chuàng)建了Service Factory服務(wù)工廠Bean。

總結(jié)

我們通過使用服務(wù)定位器模式實現(xiàn)了一種擴展 Spring 控制反轉(zhuǎn)的絕妙方法。它幫助我們解決了依賴注入未提供最佳解決方案的用例。也就是說，依賴注入仍然是首選，并且在大多數(shù)情況下不應(yīng)使用服務(wù)定位器來替代依賴注入。

審核編輯：湯梓紅