重新認識IOC & DI -- Head First Design Patterns 讀書筆記(二)

    這本書是基於Java來寫Patterns實現的,但是很多有多年J2EE程序開發經驗的人可能都沒有對Patterns有很深入的瞭解,因爲J2EE基本上都是一個MVC的模式就全部搞定了,開發的時候層次完全劃分好,即便是有一些繼承的類或者藉口也都是項目組中一、二個“牛人”寫好大家遵照着做就可以,我想這也是Patterns對於國內程序員一直都很陌生而且不易於理解的原因吧。

     所以一提到設計模式,幾乎所有做J2EE的程序員第一時間想到的都是Factory Method,讓舉個例子就是Singleton method,然後再深入說說使用工廠模式有什麼好處呢,就開始支支吾吾。我就是這樣,而我所接觸的一些程序員和我面試過的一些人無不如此 :P,也許冥冥中註定大家都只是打字員的命,那些高深的東西都留給所謂的大師去做好拉!(不知道大家怎麼去考慮這個問題)

     雖然說了解最多的就是Factory Method,但是在仔細閱讀了書中的Factory Method和Singleton Method之後,發現自己還是非常嫩 :(。特別是通過這次閱讀學習,偶發現我以前對IOC和DI的理解也是錯誤的,一道糾正寫在這裏好了。

所有語義、使用場景和優點在讀書筆記一中進行總結。

     一、Factory Method 

     首先發現的一個我常犯的錯誤就是:抽象工廠不是將工廠方法抽象出來。因爲從來沒有實際操作過,所以一直以爲Abstract Factory是將Factory mothod抽象出來的Abstract class,實際上他們直接並沒有直接聯繫,Abstract Factory只是一個接口類,其中定義了若干個對象的創建,然後由其他類實現以達到解藕的目的而已。工廠方法仍然是我們所熟悉的那個爲避免過多的使用new創造對象而將創建過程提取出來的那個Pattern,而且通常情況下工廠方法是使用的抽象類,並在其中定義一個抽象方法來實現的,目的是爲了解偶,當然,有時候也可是直接將創建方法寫進具體的類裏面。使用工廠方法一般是在只需要一個固定的構造器的時候用來解偶用的,那麼當你增加產品或者修改產品的實現的時候,它不會影響到你的構造器,因爲構造器並沒有緊耦合。

     二、 Abstract Factory Method

     而抽象工廠模式則提供一個接口來創建一組有關聯的對象而不去指定它們的具體實現類,而我們最常見的就是Spring中的Inversion of control。在以往使用Spring的過程中我一直沒有能將IOC這個概念喫透,雖然這並不影響使用,但是每當我想說服他人使用Spring的時候或講解其機理的時候就會非常的喫力,而現在我有一點小感想了,IOC只是一個抽象工廠的實現,那麼什麼控制反轉、什麼依賴注入這種生澀的概念我就可以先不予考慮,它首先就是一個抽象工廠的實現,創造一組對象的接口而沒有指明具體的實現類(這樣考慮感覺一下就容易多了)。具體的解釋可以參照老馬的經典文章:http://martinfowler.com/articles/injection.html,那麼從這裏可以得知,實現依賴注入他推薦使用構造方法的注入,而在不能滿足條件的情況下使用set方法設值注入,而Spring選擇的就是set方法,可能這個就是讓我們不好理解的地方,因爲我們是先學寫代碼後學框架然後才學Patterns(不知道其他人是否也是這個順序),或者說對代碼、框架有了一定了解後纔有了對Patterns的瞭解。

     三、IOC & DI

     那麼我們就從IOC這個抽象工廠開始,書中提出一個簡單的例子讓我們瞭解了抽象工廠的用意就是使用接口來指定構造那些對象而沒有指定具體的實現類,以達到解偶的目的,使得對象的使用者並不知道最終調用的具體類,而是在運行期動態的注入了一個實現該工廠接口的值來決定最終調用哪個類去實現。這就是書中對Inversion of control的解釋,也就是說low level component方向控制了high level component,達到控制反轉的目的。然後我們翻開很久以前就熟讀過的SpringGuide文檔,發現這裏面對IOC還有另外一種解釋,就是用容易控制了程序之間的關係,而非傳統實現中,由程序代碼直接操控。這樣控制反轉的兩種方式就出現了,也就是先前老馬在文中所說:IOC的實現可以通過兩種途徑,一是通過編碼、二是通過配置文件。(這個地方可能還有些出入,需要更深入的學習和討論纔會有更深入、準確的理解)

     四、Singlton Factory

     儘管我們對構造Singlton Factory可能很熟練,但是書中還是很詳細的寫出3種構造方法,並由最簡單的方式逐漸提出新的需求和問題以講述我們到底需要哪種方式。

     比如我們經常會看到的public static synchronized Singleton getInstance() 中的沒一個關鍵字都進行了解釋,以及性能問題,三種構造方法都是有不同的場景,而且都有相應的問題,並告訴我們:當你需要它的時候先選擇一種合適的使用,如果出現問題,再根據需求進行修改就可以了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章