大家好,我是不才陳某~
不知道大家在專案中有沒有遇到過這樣的場景,根據傳入的型別,呼叫介面不同的實現類或者說服務,比如根據檔案的型別使用 CSV解析器或者JSON解析器,在呼叫的客戶端一般都是用if else
去做判斷,比如型別等於JSON,我就用JSON解析器,那如果新加一個型別的解析器,是不是呼叫的客戶端還要修改呢?這顯然太耦合了,本文就介紹一種方法,服務定位模式Service Locator Pattern
來解決,它幫助我們消除緊耦合實現及其依賴性,並提出將服務與其具體類解耦。
推薦Java工程師技術指南:https://github.com/chenjiabin...
檔案解析器的例子
我們透過一個例子來告訴你如何使用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);
}
..
}
嘿嘿,我們已經成功地實現了我們的目標。現在再加新的型別,我們只要擴充套件新增新的解析器就行,再也不用修改客戶端了,滿足開閉原則。
推薦Java工程師技術指南:https://github.com/chenjiabin...
如果你覺得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
的文章總結了核心思想:“服務定位器背後的基本思想是擁有一個知道如何獲取應用程式可能需要的所有服務的物件。因此,此應用程式的服務定位器將有一個在需要時返回“服務”的方法。”
推薦Java工程師技術指南:https://github.com/chenjiabin...
Spring
的ServiceLocatorFactoryBean
實現了 FactoryBean
介面,建立了Service Factory
服務工廠Bean
。
總結
我們透過使用服務定位器模式實現了一種擴充套件 Spring 控制反轉的絕妙方法。它幫助我們解決了依賴注入未提供最佳解決方案的用例。也就是說,依賴注入仍然是首選,並且在大多數情況下不應使用服務定位器來替代依賴注入。
最後說一句(別白嫖,求關注)
陳某每一篇文章都是精心輸出,如果這篇文章對你有所幫助,或者有所啟發的話,幫忙點贊、在看、轉發、收藏,你的支援就是我堅持下去的最大動力!
關注公眾號:【碼猿技術專欄】,公眾號內有超讚的粉絲福利,回覆:加群,可以加入技術討論群,和大家一起討論技術,吹牛逼!