品Spring：bean定義上梁山
認真閱讀，收穫滿滿，向智慧又邁進一步。。。
技術不枯燥，先來點閒聊
先說點好事高興一下。前段時間看新聞說，我國正式的空間站建設已在進行當中。下半年，長征五號B運載火箭將在海南文昌航天發射場擇機將空間站核心艙發射升空。預計用2到3年將空間站建好。
雖然到時你們不讓我上去，不過我也為這件事出不了什麼力，算扯平了。哈哈，但是我還是會衷心的祝福你。
長征五號火箭首次採用5米大直徑的箭體結構，總加註量達到780噸，起飛時共有10臺發動機產生1078噸的推力，具備近地軌道25噸、地球同步轉移軌道14噸的運載能力。
不要誤會，本文不是講火箭的，關鍵我也講不了呀。但是我們可以分析下火箭的特點。自身體積和重量非常大，內部結構與實現極其複雜。能夠運送的物品與自身比起來微乎其微，關鍵這玩意老貴老貴了。
因此SpaceX推出的獵鷹可回收火箭，從一開始就受到了全世界的關注。回收之後可以被重新利用，不但縮短了火箭發射的週期，平均下來每次發射的成本也少了很多。享受同樣的服務，花更少的錢，不是所有人的最愛嘛。
回到程式，其實現在大部分程式設計師，包括我自己在內都應該屬於2.0或3.0版本的程式設計師，因為我們的職業生涯都是從Spring開始的。在Spring之前Java企業級應用開發標準其實是EJB（企業級JavaBean）。
EJB只是一個標準或規範，由各大服務提供商來實現。EJB非常笨重而且用起來也痛苦，關鍵還很貴。其實和火箭的性質一樣，自身的負擔太重。這個問題必須要解決。
因此，Elon Musk認識到了這點，就開始著手研製可回收火箭。在當時，Rod Johnson也認識到了EJB特點並深受其害，於是發明了Spring，輕量級、免費開源，慢慢就流行起來了。
看到了吧，在工作或生活中，凡是遇到苦逼的地方，就說明這也是一個極有可能產生大成功的地方。這個祕密我可是告訴諸位了，能不能成功就看你們的了。哈哈。
其實Spring現在也已經變得足夠複雜了。
要想渡人，必先渡己
易中天老師曾說過，能夠製造工具標誌著人類的誕生。目前人類建造的文明，哪一個是通過雙手刨出來的，不都是通過工具建造出來的嘛。
比如我們蓋高樓用的建材，不都是通過塔吊一點點吊上去的，隨著建材的堆砌，樓越來越高。那麼我們來思考一個問題，塔吊本身是如何上去的？
塔吊本身就是一個工具了，所以（一般情況下）不可能再有其它工具來幫它了。所以塔吊只能實現自我爬升，實際也是這樣的，相信大多人都見過，速度很慢的。
我們都在用Windows作業系統，點點滑鼠，敲敲鍵盤，用著很爽。但是在開發Windows系統本身時卻是很苦逼的一件事。
我主要想表達兩方面的意思：
如果有一天，我們能從工具的使用者變成設計者或製造者，那就厲害多了。
還有就是，一個工具在對外提供服務前，一定要解決好自身的搭建或構建問題。
Spring其實就是個工具，開發人員把業務程式碼寫好後，把類作為bean註冊到工具上，後續的執行時全部交由Spring這個工具接管，簡直不要太爽。
當然，這也是Spring存在的價值和意義。但是不要忘了，建造Spring這個工具的那批人可就不爽了，為了“取悅”這個工具的使用者天天挖空心思。
所以“品Spring”這個系列文章，是想要逐步解密Spring這個工具的建造細節，而不是教怎麼使用這個工具的。目前還不能熟練使用這個工具的小夥伴可就要加油了。
所以Spring這個工具應該優先考慮好自我的搭建，才能更好的為開發員人服務。
就像開發人員，必須有一個良好的家庭，吃飽喝足睡夠之後，才能寫出水平最高的程式碼。如果剛在家和老婆吵完架，那寫出的程式碼應該都是bug的樣子，哈哈。
相同的套路，相似的處理
編譯器是編譯程式碼的，但它本身也是程式碼。飯店的工作人員是服務客人吃飯的，但他們本身也要吃飯。指標是指向地址的，但它們本身也有地址。
描述業務的資料通常稱為業務資料，描述業務資料的資料通常稱為元資料。業務資料和元資料都是資料，只不過是取了兩個更加細化的名字罷了。
上面描述的這些情形裡面都包含了兩方面的事物，可以理解為是“一前一後”的感覺。它們既不是相同也不是不同，而是相似。即處理方式相同，側重點不同。
就以飯店為例吧，這個所有人都熟悉。給客人做的飯，要求色香味俱全，即當作藝術品來對待。員工自己吃的飯，要求味美可口簡單快捷，即當作食物來對待。
因為客人和員工的要求不同，所以處理的側重點、工序和用料不同，但是處理方式大致都一樣，無非就是煎炒炸蒸煮等等。
相信都已經明白了，如果還不清楚，就想想蓋商品房、蓋集資房和蓋職工宿舍有什麼區別？本質上沒有區別，而且還可能是同一個施工隊乾的。
回到程式，經常聽到說做中介軟體開發的人都很厲害，寫純業務程式碼的好像都是菜鳥。怎麼說呢，做中介軟體和做業務確實目的不同、側重點不同、用到的技術不同，所以要求也不同。
寫出程式碼的好壞只取決於個人水平，因為中介軟體程式碼和業務程式碼沒有本質的區別，都是對資料的操作和傳遞，都是順序分支迴圈的程式結構。
而且都是用同一個編譯器編譯，關鍵編譯器才不管你是什麼程式碼呢，反正都是Java程式碼，對吧，哈哈。
回到Spring，既然Spring能把業務開發人員寫的業務類作為bean來對待（即註冊bean定義），難道就不能把用來處理這些業務類的“系統類”（即Spring自身的類）也當作bean來對待嗎？
答案是完全可以，而且實際也是這樣做的。本來業務類和系統類就是人為劃分的，本質上都是程式，沒啥區別。
都作為bean來對待後，帶來了一個非常好非常好的好處，就是統一了程式設計模型，這非常重要。
就是業務開發人員可以使用@Component/@Bean註冊bean定義，使用@Autowired裝配bean依賴。框架開發人員在開發Spring框架時也可以這樣使用。
這樣就模式統一、寫法統一、思維統一，當然很爽了。
可以這樣理解，在建造這個工具時，就已經可以享受這個工具帶來的便利了。
如果無法體會到這種好處的，照例通過一個小事情說明下。
比如一群中國人，彼此協作的很好，突然來了一個老外，互相又聽不懂對方，但是還要交流，只要讓翻譯在中間翻來覆去，是不是淨瞎耽誤工夫，肯定是不爽的。
當然，這個事情有時也是不成立的，比如老外是一個年輕漂亮的小姐姐，是吧，所以說任何事情都不是絕對的。
Spring統一了程式設計模型後，Spring自身的類和業務類都註冊了bean定義，那這些bean定義間真的就完全一樣嗎？
答案當然是否定的，畢竟作用不同，肯定是有差別的，只是大小罷了。
身先士卒，衝鋒陷陣
業務類註冊bean定義的目的是為了將來執行這個bean實現業務邏輯的。那麼它的bean定義是怎麼註冊的呢？顯然是Spring為它註冊的。
因此在Spring內部，有一個專門為其它類註冊bean定義的介面，即BeanDefinitionRegistryPostProcessor介面：
public interface BeanDefinitionRegistryPostProcessor extends BeanFactoryPostProcessor {
void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException;
}
介面只有一個方法，就是註冊bean定義。
這個介面有一個非常重要的實現類，即ConfigurationClassPostProcessor類，它裡面包含了所有Spring支援的註冊bean定義方式的實現。
因Spring統一了程式設計模型，所以這個類也被註冊了bean定義。又因為這個bean只有執行起來後才可以為其它類註冊bean定義，所有這個類無論是註冊bean定義還是執行，在時間軸上都是比較靠前的。
事實上，它是Spring註冊的第一個bean定義，bean的類就是剛才提到的那個實現類，bean的名稱是：
org.springframework.context.annotation.internalConfigurationAnnotationProcessor
說白了這個類就是用來處理那些使用註解標註的類，為它們註冊bean定義的。所以這個類它自己的bean定義註冊絕對不能再使用註解的方式，而是使用程式碼直接註冊的，可以認為是寫死的。
通過高鐵乘務員和旅客的這種情況，可能會理解的更明白些。
1、乘務員是人，旅客也是人，他們都是人。框架裡的類註冊bean定義，業務類註冊bean定義，它們都註冊bean定義。
2、乘務員必須先到達，然後才能迎接旅客，在時間軸上要靠前些。框架裡的類必須先註冊bean定義，然後才能為其它類註冊bean定義，在時間軸上同樣也要靠前些。
3、乘務員是走工作人員通道進入，旅客是正常買票/檢票進入，進入方式是不同的。框架裡的類是直接通過寫程式碼的方式註冊的bean定義，業務類是通過標註解的方式註冊的bean定義，註冊bean定義的方式也是不同的。
所以慢慢就會發現，任何上層封裝的很完美的程式碼，當一步步到達底層時，都會進行一些“特殊”的處理。這種現象並不只是程式程式碼裡才有，在歷史上一直都存在。
易中天品三國中講過一個小故事，曹操領兵打仗時定了一條軍規，凡是誰的馬踐踏了農田，是要殺頭的。有一天不湊巧，曹操自己的馬驚了，跳進了農田。
曹操喊來相關負責人，問他，“按規定應該怎麼處置啊”？答曰：“應該殺頭”。但這可是曹操啊，怎麼能殺頭呢。於是那個人又說：“身體髮膚受之於父母，我們自己沒有權力損壞”。
於是曹操就拔出劍，割下了自己的一縷頭髮，扔到了地上。這就相當於受到了非常嚴重的處罰，等於死過了。這不就是特殊處理嘛。
這也說明了，跟領導混的，必須得有幾把刷子，畢竟古語道，伴君如伴虎啊。
扯得有點遠了，再回到正題。
Spring為了使bean定義的處理更加靈活，還提供了一個特殊的介面，即BeanFactoryPostProcessor介面，也就是上面那個介面的父介面：
public interface BeanFactoryPostProcessor {
void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
}
當執行到這個介面的時候，所有的bean定義其實都已經註冊好了，所以這個介面的目的就是再給一次修改（或完善）bean定義的機會。
當這個介面執行完後，所有的bean定義就真的確定下來了，不會再變了。
如果對Spring不是很熟悉的，只要記住下面這個總結就行了：
這兩個介面是特殊的，它們就是用來為其它類註冊bean定義或修改已註冊好的bean定義的。
這兩個介面的實現類也會被註冊bean定義，只不過在時間軸上會非常的靠前。
這兩個介面可以有多個實現類，可以通過實現排序介面進行排序，以保證邏輯上先後順序的正確性。
其實不懂這些也無所謂，不影響成為一個合格的程式設計師。
bean定義上梁山
108位梁山好漢上梁山的原因和過程各不相同，但最後都到了梁山。
bean定義的註冊方式和方法也有好幾種，但最後都能註冊成功。
因為歷史已經走到了註解和Java配置的時代，所以它們就是主角了。
使用註解註冊bean定義：
標有@Component註解的類
標有@Configuration註解的類
標有@Configuration註解的類裡標有@Bean註解的方法返回的類
這種方式既可以用於業務類的註冊，也可以用於Spring框架內部的類註冊。
優點是簡單方便，缺點是不夠靈活。尤其很難根據一個條件判斷來註冊不同的bean定義。
使用XML配置註冊bean定義：
在標有@Configuration註解的類上，使用@ImportResource註解引入XML配置檔案。
這種方式使在註解裡也能使用XML。個人覺得除非是遺留系統，否則全用註解。畢竟時代潮流不會逆轉。
使用@Import註解引入：
在標有@Configuration註解的類上，使用@Import註解引入其它標有@Configuration註解的類。
這僅用於沒有類路徑掃描功能的專案程式碼，現在大都基於SpringBoot，這種方式已經用的很少了。
使用ImportSelector介面註冊bean定義：
public interface ImportSelector {
String[] selectImports(AnnotationMetadata importingClassMetadata);
}
介面方法返回的是類名稱的陣列，這些類將會被註冊bean定義。
在實現這個介面時，可以根據不同的情況返回不同的類名稱，這就非常的靈活，實現了動態註冊bean定義的需求。
這個介面用於Spring框架內部開發，或其它框架與Spring的整合對接。
典型用法是在一個特定功能註解上使用@Import註解引入這個介面的實現類。
這個介面方法的引數importingClassMetadata是最終標有這個特定功能註解且同時標有@Configuration註解的那個類。
請參考文章末尾示例程式碼。
使用ImportBeanDefinitionRegistrar介面註冊bean定義：
public interface ImportBeanDefinitionRegistrar {
void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry);
}
這個介面方法沒有返回值，所以需要自己寫程式碼直接註冊bean定義，當然也是非常靈活的。
在用法上和上面那個介面一模一樣，包括介面方法引數的含義也一樣。
除了這種用法，還可以把這個介面的實現類的類名稱放入上面那個介面方法的返回陣列中，照樣是管用的。
這個介面的目的和上面那個介面也是一樣的。
請參考文章末尾示例程式碼。
使用BeanDefinitionRegistryPostProcessor介面註冊bean定義：
這在上一小節已經介紹了，屬於最基礎的方式。使用它可以做到儘早的註冊bean定義。
上面這幾種就是Spring支援的bean定義的註冊方式，有適合業務開發的，有適合Spring內建功能或其它框架與Spring整合的。
PS：隨著本系列文章走下去，慢慢就會明白其它框架是如何與Spring整合的，其實不難。
示例程式碼：
https://github.com/coding-new-talking/taste-spring.git
（END）
作者是工作超過10年的碼農，現在任架構師。喜歡研究技術，崇尚簡單快樂。追求以通俗易懂的語言解說技術，希望所有的讀者都能看懂並記住。下面是公眾號和知識星球的二維碼，歡迎關注！
