理解AOP

我覺得面向對象很好地解決了軟件系統中職責劃分的問題.借助于面向對象,軟件開發人員一般的,都可以將需求里的名詞轉換成系統中的對象,動詞轉換為對象里的方法.這樣非常符合人的思維方式,非常自然.

但是,問題是某些需求卻偏偏不是能用這樣的”名詞”和”動詞”就能完美的描述出來的,假如這樣的問題:需要對系統中的某些方法進行事務處理,這種需要事務代碼散布在多個類中.面對這種需求,應該怎么辦呢?最直接的辦法就是:創建一個基類(接口)或者一個助手,將事務處理的功能放在其中,并讓所有需要事務功能的類繼承這個基類(接口)或者使用這個助手.加入這樣的.需要修改的地方就會分散在多個文件中.這樣大的修改量,無疑會增加出錯的幾率,并且加大系統維護的難度,如圖:

                                     

因此,面向方面的編程(Aspect Oriented Programming,AOP)應運而生.AOP為開發者提供了一種描述橫切關注點的機制,并能夠自動將橫切關注點織入到面向對象的軟件系統中，從而實現了橫切關注點的模塊化.通過劃分Aspect代碼,橫切關注點變得容易處理.開發者可以在編譯時更改,插入或除去系統的Aspect,甚至重用系統的Aspect.” OOP只用于表示對象之間的泛化-特化(generalization-specialization)關系(通過繼承來表現),而對象之間的橫向關聯則完全用AOP來表現. 這樣,很多給對象之間橫向關聯增加靈活性的設計模式(例如Decorator等)將不再必要.”,如圖:
                                      

Spring中的Ioc

想一想以前在使用工廠模式的時候,在最早的情況下,每個工廠可能都是一個Singleton,生成對象的代碼被寫死在了類里面.后來人們覺這樣還是耦合程度太高,還不夠靈活.所以把對象的類名寫在一個XML文件里,這樣一來.問題又來了,每個工廠都有自己的讀取配置文件的代碼,通過讀取XML文件,或者通過讀取Properties,工廠里充滿了亂糟糟的和業務邏輯完全不相關的配置管理代碼,維護起來很不方便,.而Spring通過”組件工廠”把這些都集成在了一起,用一個統一的BeanFactory來管理這些配置,而且提供了更高一級的抽象:ApplicationContext

Ioc好像很神奇的樣子,其實原理和實現都很簡單,就是將要使用的對象都用XML來定義,用反射來生成,用注射的方式來使用. 其實Ioc是工廠模式的升華，Ioc可以被看作是一個大工廠，只不過這個大工廠里要生成的對象都是在XML文件中給出定義的，然后利用Java的“反射”編程，根據XML中給出的類名生成相應的對象。從實現來看，Ioc是把以前在工廠方法里寫死的對象生成代碼，改變為由XML文件來定義，也就是把工廠和對象生成這兩者獨立分隔開來，目的就是提高靈活性和可維護性。

Template Method和回調在框架中的使用

Template模式主要是用來解決這樣的一個問題:當你知道算法的具體步驟,但不知道如何去執行這些步驟.Template把如何執行這些步驟的方法都封裝成抽象的函數,并且提供一個正確的順序去執行這些步驟,而具體子類實現這些處理各個步驟的抽象方法.

業務邏輯抽象到超類集中化就是所謂的”控制反轉”了.在傳統的類庫中,一般是由客戶端來調用類庫里的方法.而在這里,卻是框架控制了用戶流程,具體的子類只是要求履行一個明確的契約.在Spring中的MVC框架里,jdbc包里.都大量的使用了Template模式.

而Java中的回調函數主要是在實現事件驅動模型的時候使用的,但是在Spring里面,回調被賦予了新的意義:通過回調接口(函數)來實現可擴展性.如jdbc包的RowcallbackHandler.