Spring你不知道的一種解耦模式
前言
不知道大傢在項目中有沒有遇到過這樣的場景,根據傳入的類型,調用接口不同的實現類或者說服務,比如根據文件的類型使用 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
的文章總結瞭核心思想: “服務定 位器背後的基本思想是擁有一個知道如何獲取應用程序可能需要的所有服務的對象。因此,此應用程序的服務定 位器將有一個在需要時返回“服務”的方法。”
Spring
的ServiceLocatorFactoryBean
實現瞭 FactoryBean
接口,創建瞭Service Factory
服務工廠Bean
。
總結
我們通過使用服務定 位器模式實現瞭一種擴展 Spring 控制反轉的絕妙方法。它幫助我們解決瞭依賴註入未提供最佳解決方案的用例。也就是說,依賴註入仍然是首選,並且在大多數情況下不應使用服務定 位器來替代依賴註入。
到此這篇關於Spring你不知道的一種解耦模式的文章就介紹到這瞭,更多相關Spring解耦模式內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- Spring中bean集合註入的方法詳解
- Spring純註解開發模式讓開發簡化更簡化
- Spring框架學習常用註解匯總
- Spring Boot中單例類實現對象的註入方式
- spring註解@Service註解的使用解析