Spring專案中用了這種解耦模式，經理對我刮目相看

前言

不知道大家在專案中有沒有遇到過這樣的場景，根據傳入的型別，呼叫介面不同的實現類或者說服務，比如根據檔案的型別使用 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旭陽』交流溝通