讀牛人技術部落格 A Java Geek,最開始覺得這樣的想法很有創意。提前使用靜态代碼塊把對象存入map容器中，在需要的時候在取。他也有提到可以使用DI的方式把需要的對象提前注入好，但是這兩種方式都會造成記憶體的浪費，因為有一些對象可能是頻繁使用，而有些對象用的機率小甚至一次都沒有用到，那麼這樣的方式是不好的。
而且，我們是去除if…else…的語句，這樣的方式雖然好像沒有了if…else…語句，但是本質上并不是最好的方式，隻是提供了一種思維方式。
讀《重構 改善既有代碼的設計》有一條就是，以多态取代條件表達式。這是才是最本質的解決方式。
這裡的去除if…else…語句，不是遇見了if…else…語句就去除。這裡是這樣描述的：你手上有個條件表達式，它根據對象類型的不同而選擇不同的行為。而不是平時編寫代碼遇見一些普通的條件表達式就去把它去除，不是這樣的。
而且，一般來說程式設計語言都有switch語句去替代if…esle…語句。從性能上看這兩個文法也隻有非常細微的差别，根本無需關心自己使用了哪個文法。
以多态取代條件表達式代碼的壞味道一：
代碼的壞味道二：
思路
将這個條件表達式的每個分支放進一個子類内的覆寫函數中，然後将原始函數聲明位抽象函數。
動機（為什麼我們要使用多态取代條件表達式？）
多态最根本的好處就是：如果你需要根據對象的不同類型而采取不同的行為，多态使你不必編寫明顯的條件表達式。
類圖
Employee
EmployeeType
Engineer
Manager
Salesman
Employee
EmployeeType
Engineer
Manager
Salseman
a, 把Employee中的原來的屬性_monthlySalary，_commission，_bonus變成最終的采用一個函數擷取。
b, 注意的地方就是誰組合了誰。這裡就是Employee組合了EmployeeType。或者可以了解為誰持有了誰的引用。
c, 其次就是一個繼承關系。
小結由于偶然讀到别人技術部落格關于if…else…的取代文章，發現這也是一個思路，但是不夠那麼好，于是記錄下《重構 改善既有代碼設計》的一個以多态取代條件表達式的範例。
雖然這樣确實處理了if…else…語句，但是一旦使用多态取代條件表達式的方式，必定會引入一個繼承或者實作體系，其實，這是增加了了解的複雜度。
面向對象的程式設計，如果增加了擴充性必定會引入設計模式，而一旦引入設計模式必定增加了解的複雜度，因為總有繼承體系和實作體系結構，這種結構也是面向對象程式設計的特色。面向對象程式設計不一定比面向過程好。在實際的編碼過程中，還是需要權衡這兩種方式。
------------------------------分割線--------------------------
玩知乎這麼久第一次發文，以後也會經常發一些工作中遇到的問題，看到的大佬可以給點意見，共同學習，共同進步。