需求spring
這裏虛擬一個業務需求,讓你們容易理解。假設有一個訂單系統,裏面的一個功能是根據訂單的不一樣類型做出不一樣的處理。函數
訂單實體:工具
service接口:blog
傳統實現繼承
根據訂單類型寫一堆的if else:接口
策略模式實現get
利用策略模式,只須要兩行便可實現業務邏輯:源碼
能夠看到上面的方法中注入了HandlerContext,這是一個處理器上下文,用來保存不一樣的業務處理器,具體在下文會講解。咱們從中獲取一個抽象的處理器AbstractHandler,調用其方法實現業務邏輯。class
如今能夠了解到,咱們主要的業務邏輯是在處理器中實現的,所以有多少個訂單類型,就對應有多少個處理器。之後需求變化,增長了訂單類型,只須要添加相應的處理器就能夠,上述OrderServiceV2Impl徹底不需改動。容器
咱們先看看業務處理器的寫法:
首先每一個處理器都必須添加到spring容器中,所以須要加上@Component註解,其次須要加上一個自定義註解@HandlerType,用於標識該處理器對應哪一個訂單類型,最後就是繼承AbstractHandler,實現本身的業務邏輯。
自定義註解 @HandlerType:
抽象處理器 AbstractHandler:
自定義註解和抽象處理器都很簡單,那麼如何將處理器註冊到spring容器中呢?
具體思路是:
一、掃描指定包中標有@HandlerType的類;
二、將註解中的類型值做爲key,對應的類做爲value,保存在Map中;
三、以上面的map做爲構造函數參數,初始化HandlerContext,將其註冊到spring容器中;
咱們將核心的功能封裝在HandlerProcessor類中,完成上面的功能。
HandlerProcessor:
ClassScaner:掃描工具類源碼
HandlerProcessor 須要實現BeanFactoryPostProcessor,在spring處理bean前,將自定義的bean註冊到容器中。
核心工做已經完成,如今看看HandlerContext如何獲取對應的處理器:
HandlerContext:
BeanTool:獲取bean工具類
#getInstance方法根據類型獲取對應的class,而後根據class類型獲取註冊到spring中的bean。
最後請注意一點,HandlerProcessor和BeanTool必須能被掃描到,或者經過@Bean的方式顯式的註冊,才能在項目啓動時發揮做用。
總結
利用策略模式能夠簡化繁雜的if else代碼,方便維護,而利用自定義註解和自注冊的方式,能夠方便應對需求的變動。本文只是提供一個大體的思路,還有不少細節能夠靈活變化,例如使用枚舉類型、或者靜態常量,做爲訂單的類型,相信你能想到更多更好的方法。