來源公眾號逐碼 ，
作者逅弈
有一天晚上我腦海中突然冒出來一個問題：「怎樣管理我們代碼中的對象」。
小弈是剛工作時的我，他說：通過 new 來創建一個對象然後直接使用就好了啊。
你們看，我有一個 HelloWorld 類，我用 new 就能直接創建一個對象，然後就能使用這個對象中所有的方法了，多簡單啊。
二弈是工作兩年的我，他一臉鄙視的對小弈說，你別整天 HelloWorld 好不好，還有啊，除了 new 你就不會其他的了，能不能有點追求啊？
小弈對二弈說那你說除了 new 還有什麼辦法啊？
二弈說可以通過 Class 的 newInstance 或者 Constructor 的 newInstance 來創建對象實例啊。
不過你得記住，Class 的 newInstance 只能對那些擁有可見的(Accessible)無參構造函數的類，才能進行對象的實例化，而 Constructor 就沒有這些限制。
大弈是工作三年的我，他說，雖然你們的方法都可以用來創建對象，但都還是手動創建的，太原始了，生產力太低。
工欲善其事，必先利其器，我們也得找個高效的生產力工具。IOC 容器你們了解吧？
以前我們在一個對象中如果要調用另外一個對象的方法時，都是通過 new 或者反射來手動創建該對象，但是每次都這樣做太累了，並且類之間的耦合也很高。
通過 IOC 容器，我們可以把所有的對象交給容器來管理，在使用之前只需要定義一下對象，然後再使用到該對象時，IOC 容器就會幫我們把該對象初始化好，這樣是不是更方便呢？
大弈說完，舉了一個例子：
IOC 容器通過一種叫 Bean 的註解，在系統啟動時掃描所有通過 Bean 標註的類，對這些類進行實例化，然後將所有的對象都保存在容器中。再掃描所有通過 Autowired 標註的屬性或者方法，從容器中找到與之匹配(通過名稱或者類型等)的對象將具體的對象賦值給這些屬性。這樣我們就可以直接將這些對象拿來使用了，作為一個伸手黨是不是很幸福啊。
老弈是工作五年的我，他聽了大弈的話之後，提出了一個問題，對於新的項目可以使用這種 IOC 的容器，可是對於那些遺留的老項目來說，要使用 IOC 來改造代價會比較大，不太符合實際。
比如在一個遺留的老項目中，有一個核心的接口 Handler:
public interface Handler {
RES handle(REQ request);
}
Handler 接口有很多的實現類，我們需要對不同的請求來調用不同的 Handler 實現類進行處理，如果用 IOC 容器來管理這些實現類，顯然不太合適，因為我們處理之前是不知道該用哪個 Handler 實現類的。
大弈想了想，如果 Handler 接口只有幾個固定的實現類，並且在使用時只會使用一個來進行處理，那麼倒是可以在啟動前通過配置的方式來確定具體使用哪種 Handler ，比如可以通過 @Conditional 根據某些條件來確定加載具體的對象，但是這種要在使用時才能確定 Handler 對象的類型確實比較棘手。
老弈看大家都不說話了，就繼續說了下去。
為了要在調用方法時使用不同的 Handler 來處理不同的而請求，需要確定兩種類，一種是請求類，一種是處理類，並且要讓請求類和處理類一一對應起來。
假設我們的請求類是一個 Packet 類，每一個具體的請求類都繼承自這個基類。
那麼想要確定每一個具體的 Packet 是什麼類型的，可以有很多種方法，可以為每個 Packet 取一個唯一的名字，例如：
public abstract class Packet {
public abstract String name();
}
也可以為每一個 Packet 指定一個標誌，例如：
public abstract class Packet {
public abstract int symbol();
}
但是不管哪種方式，每一個 Packet 的實現類都需要實現抽象類中的方法，來「標誌」自己是哪種 Packet。
我們以第二種方式舉例，假設我們有兩個具體的 Packet：
這樣當我們接收到 request 對象時，通過調用 request.symbol() 就知道這個 request 是哪種類型的 Packet 了，這時只要找到具體的 Handler 實現類來處理就可以了。
那請求類已經可以確定了，怎樣確定 Handler 處理類呢？我們是否也可以在 Handler 接口中定義一個 symbol 方法呢，像這樣：
public interface Handler {
int symbol();
RES handle(REQ request);
}
這樣的話，只要在所有的實現類中實現 symbol 方法來標註該 Handler 是用來處理何種 request 的即可。
最後把所有的 Handler 實現類都實例化後保存在一個 HandlerProvider 中，要使用時再到 HandlerProvider 中來獲取即可：
public interface HandlerProvider {
Handler getHandler(int symbol);
}
那怎樣獲取到所有的 Handler 的實現類呢，有兩種方法。
一種是通過 ServiceLoader.load(Handler.class) 的方式來獲取，不過這種通過 spi 的方式需要在項目的 resources/META-INF/services/ 目錄下創建一個 xxx.Handler 的文件，並在文件中將所有 Handler 的實現類的完全類限定符列出來。
另一種比較簡單的方式是通過掃描的方式，獲取到所有 Handler 的實現類。
到現在為止，我們的實現還算可以，但是有一個問題，那就是在 Handler 接口中我們增加了一個方法，這樣做就對原來的代碼進行了侵入。
為了讓原來的代碼保持不變，我們可以定義一個註解來標註在所有的 Handler 實現類上，比如這樣：
這樣就將 Handler 的實現和標註進行了解耦了，也可以通過掃描 @Symbol 註解來獲取到所有的 Handler 實現類，不過這樣做的缺點就是假如我忘記對某個 Handler 實現類添加 @Symbol 註解，到時候就獲取不到該 Handler 了。
大家聽完老弈的話之後，都陷入了沉思，我靠，還可以這麼玩，真有趣。
這時候現在的我，也就是逅弈，說了一句，如果我有一個接口，他只有幾個固定的實現類，我不想搞那一套那麼重的實現方式，但是我也需要動態的獲取實現類來對請求進行處理，那我該怎麼辦呢？
比如我有一個序列化的接口，如下所示：
public interface Serializer {
byte[] serialize(Packet packet);
}
然後只有五種具體的序列化的實現類，如下所示：
那麼我們該怎麼確定使用哪種序列化方式對參數 packet 進行序列化呢？
使用老弈剛剛說的那一套也確實能夠實現，不過太麻煩了，又得對 Packet 定義 symbol，又得對 Hander 實現類進行標註，還得掃描所有的實現類。
我只有五個實現類，不需要搞那麼麻煩的。
其實很簡單，只需要定義一個枚舉類，表示序列化的算法，然後對 Packet 增加一個 algorithm 方法用來表示，使用何種序列化算法，如下所示：
然後定義一個 SerializerChooser 根據不同的算法選擇不同的 Serializer 實現類即可：
public interface SerializerChooser {
Serializer choose(byte algorithm);
}
因為根據算法是可以知道對應的序列化接口的，所以就沒有必要去掃描了，直接把幾種序列化的實現類枚舉出來即可，對象的實例可以使用單例模式，如下所示：
我說完後，大家又一次陷入了沉思，我知道大家都在思考，他們會在每一次思考中獲得進步和成長，正如我在思考後得到成長一樣。
小鳥總有一天會成長為老鳥，我還走在成長的路上。