有一天晚上我腦海中突然冒出來一個問題：“怎樣管理我們代碼中的對象”误续。

小弈是剛工作時的我花盐，他說：通過 new 來創(chuàng)建一個對象然后直接使用就好了啊叼屠。

public class HelloWorld {
    public void hello() {
        System.out.println("hello world!");
    }
}
HelloWorld helloWorld = new HelloWorld();
helloWorld.hello();

你們看，我有一個 HelloWorld 類谴忧，我用 new 就能直接創(chuàng)建一個對象，然后就能使用這個對象中所有的方法了角虫，多簡單啊沾谓。

二弈是工作兩年的我，他一臉鄙視的對小弈說戳鹅，你別整天 HelloWorld 好不好均驶，還有啊，除了 new 你就不會其他的了枫虏，能不能有點追求案狙ā爬虱？

小弈對二弈說那你說除了 new 還有什么辦法啊伟骨？

二弈說可以通過 Class 的 newInstance 或者 Constructor 的 newInstance 來創(chuàng)建對象實例啊饮潦。

不過你得記住，Class 的 newInstance 只能對那些擁有可見的(Accessible)無參構造函數的類携狭，才能進行對象的實例化继蜡，而 Constructor 就沒有這些限制。

大弈是工作三年的我逛腿，他說稀并，雖然你們的方法都可以用來創(chuàng)建對象，但都還是手動創(chuàng)建的单默，太原始了碘举，生產力太低。

工欲善其事搁廓，必先利其器引颈，我們也得找個高效的生產力工具。IOC 容器你們了解吧境蜕？

以前我們在一個對象中如果要調用另外一個對象的方法時蝙场，都是通過 new 或者反射來手動創(chuàng)建該對象，但是每次都這樣做太累了粱年，并且類之間的耦合也很高售滤。

通過 IOC 容器，我們可以把所有的對象交給容器來管理台诗，在使用之前只需要定義一下對象完箩，然后再使用到該對象時，IOC 容器就會幫我們把該對象初始化好拉队，這樣是不是更方便呢弊知？

大弈說完，舉了一個例子：

@Bean
public class RegisterService {
    public void register() {
        // do register
    }
}
@Bean
public class LoginService {
    public void login() {
        // do login
    }
}
@Bean
public class HelloWorld {
    @Autowired
    private RegisterService registerService;
    @Autowired
    private LoginService loginService;
    public void hello() {
        // 注冊
        registerService.register();
        // ...
        // 登錄
        loginService.login();
    }
}

IOC 容器通過一種叫 Bean 的注解粱快，在系統(tǒng)啟動時掃描所有通過 Bean 標注的類吉捶，對這些類進行實例化，然后將所有的對象都保存在容器中皆尔。再掃描所有通過 Autowired 標注的屬性或者方法呐舔，從容器中找到與之匹配(通過名稱或者類型等)的對象將具體的對象賦值給這些屬性。這樣我們就可以直接將這些對象拿來使用了慷蠕，作為一個伸手黨是不是很幸福啊珊拼。

老弈是工作五年的我，他聽了大弈的話后流炕，提出了一個問題澎现，對于新的項目可以使用這種 IOC 的容器仅胞，可是對于那些遺留的老項目來說，要使用 IOC 來改造是不太符合實情的剑辫。

我舉個例子干旧，在一個遺留的老項目中，有一個核心的接口 Handler:

public interface Handler<REQ, RES> {
    RES handle(REQ request);
}

Handler 接口有很多的實現類妹蔽，我們需要對不同的請求來調用不同的 Handler 實現類進行處理椎眯，如果用 IOC 容器來管理這些實現類，顯然不太合適胳岂，因為我們處理之前是不知道該用哪個 Handler 實現類的编整。

大弈想了想，如果 Handler 接口只有幾個固定的實現類乳丰，并且在使用時只會使用一個來進行處理掌测，那么倒是可以在啟動前通過配置的方式來確定具體使用哪種 Handler ，比如可以通過 @Conditional 根據某些條件來確定加載具體的對象产园，但是這種要在使用時才能確定 Handler 對象的類型確實比較棘手汞斧。

老弈看大家都不說話了，就繼續(xù)說了下去什燕。

為了要在調用方法時使用不同的 Handler 來處理不同的而請求断箫，需要確定兩種類，一種是請求類秋冰，一種是處理類，并且要讓請求類和處理類一一對應起來婶熬。

假設我們的請求類是一個 Packet 類剑勾，每一個具體的請求類都繼承自這個基類。

那么想要確定每一個具體的 Packet 是什么類型的赵颅，可以有很多種方法虽另，可以為每個 Packet 取一個唯一的名字，例如：

public abstract class Packet {
    public abstract String name();
}

也可以為每一個 Packet 指定一個標志饺谬，例如：

public abstract class Packet {
    public abstract int symbol();
}

但是不管哪種方式捂刺，每一個 Packet 的實現類都需要實現抽象類中的方法，來“標志”自己是哪種 Packet募寨。

我們以第二種方式舉例族展，假設我們有兩個具體的 Packet：

public class RegisterPacket extends Packet {
    // 注冊所需要的其他參數
    int symbol() {
        return 1;
    }
}
public class LoginPacket extends Packet {
    // 登錄所需要的其他參數
    int symbol() {
        return 2;
    }
}

這樣當我們接收到 request 對象時，通過調用 request.symbol() 就知道這個 request 是哪種類型的 Packet 了拔鹰，這時只要找到具體的 Handler 實現類來處理就可以了仪缸。

那請求類已經可以確定了，怎樣確定 Handler 處理類呢列肢？我們是否也可以在 Handler 接口中定義一個 symbol 方法呢恰画，像這樣：

public interface Handler<REQ, RES> {
    int symbol();
    RES handle(REQ request);
}

這樣的話宾茂，只要在所有的實現類中實現 symbol 方法來標注該 Handler 是用來處理何種 request 的即可。

public RegisterHandler implements Handler<RegisterPacket, RES> {
    int symbol(){
        return 1;
    }
    RES handle(RegisterPacket request){
        // 具體的處理方法
    }
}
public LoginHandler implements Handler<LoginPacket, RES> {
    int symbol(){
        return 2;
    }
    RES handle(LoginPacket request){
        // 具體的處理方法
    }
} 

最后把所有的 Handler 實現類都實例化后保存在一個 HandlerProvider 中拴还，要使用時再到 HandlerProvider 中來獲取即可：

public interface HandlerProvider {
    Handler getHandler(int symbol);
}

那怎樣獲取到所有的 Handler 的實現類呢跨晴，有兩種方法。

一種是通過 ServiceLoader.load(Handler.class) 的方式來獲取片林，不過這種通過 spi 的方式需要在項目的 resources/META-INF/services/ 目錄下創(chuàng)建一個 xxx.Handler 的文件端盆，并在文件中將所有 Handler 的實現類的完全類限定符列出來。

另一種比較簡單的方式是通過掃描的方式拇厢，獲取到所有 Handler 的實現類爱谁。

到現在為止，我們的實現還算可以孝偎，但是有一個問題访敌，那就是在 Handler 接口中我們增加了一個方法，這樣做就對原來的代碼進行了侵入衣盾。

為了讓原來的代碼保持不變寺旺，我們可以定義一個注解來標注在所有的 Handler 實現類上，比如這樣：

@Symbol(1)
public RegisterHandler implements Handler<RegisterPacket, RES> {
    RES handle(RegisterPacket request){
        // 具體的處理方法
    }
}
@Symbol(2)
public LoginHandler implements Handler<LoginPacket, RES> {
    RES handle(LoginPacket request){
        // 具體的處理方法
    }
} 

這樣就將 Handler 的實現和標注進行了解耦了势决，也可以通過掃描 @Symbol 注解來獲取到所有的 Handler 實現類阻塑，不過這樣做的缺點就是假如我忘記對某個 Handler 實現類添加 @Symbol 注解，到時候就獲取不到該 Handler 了果复。

大家聽完老弈的話之后陈莽，都陷入了沉思，我靠虽抄，還可以這么玩走搁，真有趣。

這時候現在的我迈窟，也就是逅弈私植，說了一句，如果我有一個接口车酣，他只有幾個固定的實現類曲稼，我不想搞那一套那么重的實現方式，但是我也需要動態(tài)的獲取實現類來對請求進行處理湖员，那我該怎么辦呢贫悄？

比如我有一個序列化的接口，如下所示：

public interface Serializer {
    byte[] serialize(Packet packet);
}

然后只有五種具體的序列化的實現類娘摔，如下所示：

public class JdkSerializer implements Serializer {
    @Override
    public byte[] serialize(Packet packet) {
        // 具體的序列化操作
    }
}
public class FastJsonSerializer implements Serializer {
    @Override
    public byte[] serialize(Packet packet) {
        // 具體的序列化操作
    }
}
public class HessianSerializer implements Serializer {
    @Override
    public byte[] serialize(Packet packet) {
        // 具體的序列化操作
    }
}
public class KryoSerializer implements Serializer {
    @Override
    public byte[] serialize(Packet packet) {
        // 具體的序列化操作
    }
}
public class ProtoStuffSerializer implements Serializer {
    @Override
    public byte[] serialize(Packet packet) {
        // 具體的序列化操作
    }
}

那么我們該怎么確定使用哪種序列化方式對參數 packet 進行序列化呢清女？

使用老弈剛剛說的那一套也確實能夠實現，不過太麻煩了晰筛，又得對 Packet 定義 symbol嫡丙，又得對 Hander 實現類進行標注拴袭，還得掃描所有的實現類。

我只有五個實現類曙博，不需要搞那么麻煩的拥刻。

其實很簡單，只需要定義一個枚舉類父泳，表示序列化的算法般哼，然后對 Packet 增加一個 algorithm 方法用來表示，使用何種序列化算法惠窄，如下所示：

public enum SerializeAlgorithm {
    JDK((byte) 1),
    FAST_JSON((byte) 2),
    HESSIAN((byte) 3),
    KRYO((byte) 4),
    PROTO_STUFF((byte) 5);
    private byte type;
    SerializeAlgorithm(byte type) {
        this.type = type;
    }
}
public abstract class Packet implements Serializable {
    public abstract byte algorithm();
}

然后定義一個 SerializerChooser 根據不同的算法選擇不同的 Serializer 實現類即可：

public interface SerializerChooser {
    Serializer choose(byte algorithm);
}

因為根據算法是可以知道對應的序列化接口的蒸眠，所以就沒有必要去掃描了，直接把幾種序列化的實現類枚舉出來即可杆融，對象的實例可以使用單例模式楞卡，如下所示：

public class DefaultSerializerChooser implements SerializerChooser {
    private DefaultSerializerChooser() {

    }
    public static SerializerChooser getInstance() {
        return Singleton.get(DefaultSerializerChooser.class);
    }
    @Override
    public Serializer choose(byte algorithm) {
        SerializeAlgorithm serializeAlgorithm = SerializeAlgorithm.getEnum(algorithm);
        switch (serializeAlgorithm) {
            case JDK: {
                return Singleton.get(JdkSerializer.class);
            }
            case FAST_JSON: {
                return Singleton.get(FastJsonSerializer.class);
            }
            case HESSIAN: {
                return Singleton.get(HessianSerializer.class);
            }
            case KRYO: {
                return Singleton.get(KryoSerializer.class);
            }
            case PROTO_STUFF: {
                return Singleton.get(ProtoStuffSerializer.class);
            }
            default: {
                return null;
            }
        }
    }
}

我說完后，大家又一次陷入了沉思脾歇，我知道大家都在思考蒋腮，他們會在每一次思考中獲得進步和成長，正如我在思考后得到成長一樣藕各。

小鳥總有一天會成長為老鳥池摧，我還走在成長的路上。