【正文】 Christopher Alexander 說，“每個模式描述了一個在我們身邊不斷重復發(fā)生著的問題，已經(jīng)對該問題的解決方案的核心。盡管 Alexander 講的是建筑領域的模式，對于軟件建構(gòu)，這個說法也同樣適用。 用一兩個詞來描述模式的問題和效果。模式名幫助我們思考，幫助我們與他人交流設計思想和設計結(jié)果。問題描述 了給定背景下反復出現(xiàn)的問題，以及在什么時候可以使用該模式。作用力表示問題的各個方面對特定解決方案的影響。 解決方案描述了該如何解決上述重復出現(xiàn)的問題，或者說，如何平衡相關的作用力。因為模式就像一個模板，它可用于 解決 一定條件下重復出現(xiàn)的不同問題，所以解決方案并不描述一個特定的設計或者實現(xiàn)，而是提供一個更為抽象的概念，并對軟件設計進行描述。效果描述了 應用一個模式所能夠達到的效果已經(jīng)該模式所權(quán)衡的問題。 模式的作用 模式描述了在特定環(huán)境下反復出現(xiàn)的問題，并提供了該問題的一個解決方案。 模式并非刻意發(fā)明或創(chuàng)造出來的，而是工程師們根據(jù)其自身的經(jīng)驗提煉出來的。由于模式是用于解決特定一類問題的通用的解決方案，這就決定了其不能描述具體的實現(xiàn)，而必須在更高的抽象上描述問題。通過對象間的協(xié)作，從而解決該問題。精心選擇的模式名會成為廣外人知的設計語言的一部分，有助于對設計問題及其解決方案展開有效的討論。 模式是一種記錄軟件架構(gòu)的手段 。 模式有助于創(chuàng)建具有指定特征的軟件。每一種模式都有描述了使用該模式所能夠達到的效果，這基本上就覺得了應用該模式的軟件會成長為什么樣。 每個模式都描述了一組預定義的組件 ， 這些組件扮演的角色以及它們之間的關系 ， 可用于規(guī)范軟件結(jié)構(gòu)的特定方面 。 3 模式有助于控制軟件的復雜度。通過明確各個組件的角色以及它們之間的關 系，在軟件開發(fā)過程中，我們可以僅僅關注一個單獨的組件，而不需要花費多余的精力去考慮整個系統(tǒng)?，F(xiàn)在，我們需要用戶最先看到的頁面 —— 注冊。然后，對于很多的新手，不出意外的， 寫出的代碼（見附錄 A）卻幾乎可以肯定會包含一系列的問題 。然后，由于 Android 并不允許在主線程中執(zhí)行網(wǎng)絡操作，我們新開了一個單獨的線程，用以將注冊信息 發(fā)往 服務器。 為了解決問題 1，我們可以將 Runnable 實現(xiàn)為靜態(tài)的內(nèi)部類，如此一來，便 不會意外地將 Activity 的引用泄露出去。 用戶每點擊按鈕一次，便新創(chuàng)建一個線程。這將使得應用和整個系統(tǒng)運行緩慢，而我們的用戶，也將會由于無法忍受這體驗而永遠不再使用這款 APP。 沒錯，我們可以利用它減少線程創(chuàng)建、銷毀的開銷。 有經(jīng)驗的開發(fā)者會發(fā)現(xiàn)另外一個非常嚴重的問題。應用的邏輯通常不會發(fā)生太多的改變，而 UI 卻往往是改動之源。但是，既然他們在同一個文件里，而你打開了那個文件進行修改，那么，就存在破壞的可能。同時，將 UI 和邏輯分離，對于應用對編寫也有非常大的益處。注意力的集中，意味著我們可以專注于更細的細節(jié)上，編寫出更好、更健壯的應用。不出意外，幾乎每一個頁面，都會有網(wǎng)絡操作。這嚴重得違反了 DRY 原則，必將導致一個維護的噩夢。 上一小節(jié)我們討論對于一個特定的注冊頁面的面臨的問題。 更進一步講，所有需要和服務器進行通信的 APP 都將面對這同一個問題。但是，我們也不想在每個命令對象中使用 WeakReference。既然使用他們的目的是一致的，那么，我們就完全有理由用一個復用的組件來完成這一功能。雖然“分離”二字很簡單，并且做起來，也似乎不難做到將應用的 UI 和邏輯分開。我們希望整個應用有一致的架構(gòu)，我們希望底層組件能夠得到盡可能多的復用。 對于 UI 和邏輯分離的問題，我們希望不僅僅是通過口頭或者文檔的形式進行約束。所以，我們希望在選定了框架之后，能夠從語法層面約束使用者。 同時，對于 UI 和邏輯分離的問題，我們需要引導用戶以分離的思維去考慮應用6 的設計，并使用框架實現(xiàn)強制用戶進行分離。盡管我們希望構(gòu)件一個全局性的架構(gòu)，以期提供整體的一致性 。但是，我們能夠做到的是，盡可能地讓其 可擴展。更進一步，如果在這所有問題中存在著一個子集，它們需要一種更為特化的解決方案，我們可以對原有的基礎框架進行擴展，從而用這個新的特化的框架來決定這些問題。 而不試圖提供過多無謂的功能。 7 3 架構(gòu)的選擇 經(jīng)典的 MVC 模式 提起 UI 和邏輯的分離，相信很多人最先想到的便是 MVC （ ModelViewController）模式了。在 MVC 模式里，共包含三種類型的對象，模型 Model 是應用對象，視圖 View 用于向用戶展示，而控制器 Controller 定義了 View 對于用戶輸入的響應方式。 MVC 通過同時使用觀察者模式和 策略模式分離視圖和模型，同時提供對不同 UI 邏輯的支持。視圖必須保證它的顯示正確地反映了模型的狀態(tài)。 模型的變更傳播機制確保應用程序的數(shù)據(jù)發(fā)生變化時，所有的觀察者將在正確的時間得到通知。 這種方法 還 可以讓你為一個模型提供不同的多個視圖的表現(xiàn)形式，為能夠為一個模型創(chuàng)建新的視圖而無需重寫模型。 圖 MVC 模式 8 而對于 View 和 Controller， 則是策略模式的一個例子。通過定義一個算法族，我們可以動態(tài)或靜態(tài)地替換對應的策略。 通過將模型、視圖和控制器分離，可更換模型的視圖和控制器，甚至在運行階段都可以替換用戶界面。首先， MVC 三個組件存在著一個環(huán)狀的依賴關系 。不僅如此，環(huán)狀依賴也提高了單元測試的難度。 此外，視圖和控制器的關系過于緊密。不僅如此，視圖和控制器與模型也是緊耦合的。 一種變體 —— MVP 模式 由于上述 MVC 模式的一系列問題，加之其誘人的優(yōu)點，于是， 便 有了它的一個變體 —— MVP 模式。 圖 MVP 模式 在 MVP 模式中，模型 Model 組件提供了一個定義用于展示的數(shù)據(jù)的接口，并根據(jù)用戶的動作做出相應的處理邏輯。9 而表現(xiàn)者 Presenter 則 作為一個中間人的角色而存在，所有的表現(xiàn)邏輯都存在于表現(xiàn)者Presenter 中。所以， Presenter 也因此有了另一個名稱 —— 超級控制器。視圖并不主動處理 UI 的更新和用戶動 作，它所做的，就是非常單一的功能 —— 展示用戶界面。 實際上，對于視圖所處理的邏輯的多少，每個不同的實現(xiàn)都不盡相同。 在這種情況下，當用戶觸發(fā) View 組件的一個事件回調(diào)時，它不會做任何的處理，而僅僅是調(diào)用presenter 的一個沒有參數(shù)也沒有返回值的方法。最 后， Presenter 操作 Model 組件，得到結(jié)果后又相應地更新 UI。這通常更適用于基于 web 的架構(gòu)，這種情況下， View 組件通常運行在用戶的瀏覽器中，所以，對于一些交互命令， View 組件是一個更好的處理場所。這使得 MVP 更加地適合于單元測試。而對于 MVC 的優(yōu)點，在這里也同樣保持著。如果交換邏輯需要作出修改，也可以通過替換 Presenter 這個組件而得到所需的效果。 遺憾的是， MVP 也有其缺點。即使是 Model 中的一個小小的改變，也要跨過千山萬水才能夠表現(xiàn)在 UI 上。所幸的是，這種情況發(fā)生的幾率實在太低，所以一般不會是太大的問題。大多數(shù)時候，我們根本不需要對數(shù)據(jù)進行格式化，只是從 Model 取出，然后直接應用于 View 組件的更新。 10 更進一步 —— MVVM 模式 前面 我們提到 MVP 模式中，將數(shù)據(jù)顯示到 View 組件通常是一件比較無趣而繁瑣的工作。MVVM 同樣是對圖形用戶界面與應用邏輯的分離。 MVVM 中的 View Model 組件是一個值轉(zhuǎn)換器；這意味著 View Model 的職責是從將 Model 類得來的數(shù)據(jù)對象進行轉(zhuǎn)化，使之更易于管理和表現(xiàn)。 View Model 可以使用中間人模式進行實現(xiàn)，它處理 View 所支持的所有 對后端邏輯的訪問 控制。 圖 MVVM 模式 從組件的依賴關系上看， MVVM 和 MVP 非常地相似，唯一的不同是， MVP 里，我們程序員自己手動執(zhí)行了一個所謂 data binding 的動作。 View 組件也是，作為一個用戶界面而存在。與 MVC 中的 Controller 和 MVP 中的 Presenter 不同的是， MVVP 有一個 binder。聲明式的對數(shù)據(jù)、命令和 UI 的綁定在 MVVM 模式中是隱式的。 11 毫無例外， MVVM 也有其缺點。而對于復雜的交互邏輯，靠程序 （ binder） 進行自動的數(shù)據(jù)綁定又顯得過于的力不從心。 回歸簡樸 —— DocumentView 模式 MVC 存在著環(huán)狀依賴， MVP 調(diào)用鏈過長， MVVM 對簡單應用過于復雜，對復雜應用支持又不足，那么，我們又應該選擇哪一個模式呢？ 回想前面我們討論過的問題，我們需要的是 UI 和邏輯分離，需要它足 夠的輕量，并具有相當?shù)目蓴U展性。那么，這樣的架構(gòu)模式存不存在呢？答案是，存在，它就是所謂的 DocumentView 模式。這里的 View ，和 MVC 中的 View并沒有什么顯著的差別， 同樣的用于向用戶展示信息和提供交互。 使用 DocumentView 模式的最為著名的架構(gòu)，應該就屬微軟的 MFC 框架了。 Document 負責管理數(shù)據(jù)并更新 View， View 組件則用于向用戶展示數(shù)據(jù)和提供交互功能。 但是，如果僅僅是 UI 和邏輯分離，并不足以使我們選擇這么一個架構(gòu)。 對于絕大多數(shù)的 Android 應用，一個 Model 僅僅對應一個 View， 我們并沒有不需要 MVC 同步更新多個 View 組件的功能。可以說， MVC 并不適用于 Android 應用的開發(fā)。對于性能非常重要的應用而已，中間的 Presenter 是不能忍受的。 對于 MVVM， 不使用他的原因和上面 所述的它的缺點一樣。 最為重要的一點是，由于它們都是基于 UI 和邏輯分離的原則所設計的，四個模式都有其共通的地方。 假定我們現(xiàn)在的 UI 交換邏輯過于的復雜， DocumentView 已經(jīng)無法滿足我們的需求。需要注意的一點是，盡管此時已經(jīng)變化為 MVP 模式，但我們還是重用了低層 DocumentView 框架的實現(xiàn)。即便我們使用這樣的術(shù)語，但是，這并不意味著，各個組件是在和實體的類進行交談。 目前 Android 的 Native 應用主要是使用 Java 進行 開發(fā)的，利用 Java 的語言特性，我們完全可以做得更好。 組件并不互相直接就進行通信，而是通過引用一句接口。 雙方通過接口進行引用， 使得在利用對方提供的接口時 ，只能使用接口所提供的抽象，這大大減少了需要同時關注的問題，很好地隔離了復雜度。我們并不關心 View 和 Document 的實際類型是什么，我們只知道，那個類實現(xiàn)了我們所需的接口。甚至，與 MVC、 MVP 等提供的動態(tài)性一樣，我們也可以在運行時動態(tài)地選擇 View 和 Document 的實現(xiàn)。通過對業(yè)務進行分析并制定接口，可以避免在尚不清楚邏輯的情況下過快地進行編程。還應注意的是，接口的命名應該是描述式的，它表明所完成的功能，而不是如何完成該功能。 14 4 框架的實現(xiàn) Document 實例的創(chuàng)建 Android 的 UI 是基于所謂的 Activity 實現(xiàn)的，一個 Activity 就相當于一個窗口。由于一個 Android 應用首先啟動的幾乎總是 Activity， 并且 它是由 Android Runtime 啟動的，所以，剩下的我們需要關心的，表示何時實例化 Document 的實例，又在哪里進行實例化。而這一系列的步奏，無疑每個 Activity 都需要。通過使用泛型參數(shù)，我們不再需要提供一個公共的 Document 或 View 接口，而是由 Java 編譯器幫助我 們進行安全的類型轉(zhuǎn)換。 由于我們希望由超類統(tǒng)一對 Document 進行實例化，在此，我們不得不做出一些折衷。 具體的實現(xiàn)代碼見附錄 B。也就是說， Document 接口有一個公共的祖先 BasicDocumentOps 接口。 void onDestroy()。 } 通過增加一個 setView 方法，我們可以利用它設置 View 組件的引用。 使用該超類時，子類只需要回調(diào)超類的 onCreateDocument 方法， GenericActivity 即15 會自動完成 Document 的創(chuàng)建工作： onCreateDocument(view, )。也就是說，對于傳遞給 Document 的實例，我們必須使用 WeakR