MVC減少編程複雜性

 MVC減少編程複雜性

　　隨著物件導向的語言（如Java）的迅速發展和普及，越來越多的編程人員開始在應用開發中使用這些語言。然而原有的開發語言（即面向操作的開發語言如C＋＋等）在短時間內還不可能退出曆史舞台，因此現在就出現了物件導向的語言和傳統的面向操作的語言共存的局面。在設計應用中同時使用兩類不同的語言（混合語言設計）比過去只使用一類語言會帶來許多新的問題，其中複雜性就是混合語言設計中最經常遇到的問題。下面我們探討混合語言設計中可能導致複雜性增加的地方，以及如何減少以至消除這些複雜性。

　　複雜性

　　複雜性是應用開發過程中最令人頭疼的一個問題。每當在一個應用中增加一個功能時，它的複雜性通常呈幾何級的增長。這種複雜性往往導致程式的開發無法再繼續下去。這也是現在為什麼許多應用只有Beta版本而沒有正式版的原因。

　　專家將應用開發過程產生的複雜性分為兩類，即非本質的（accidental）和本質的（essential）。本質的複雜性是對於解決目標問題所必然產生的複雜性，非本質的複雜性是由於選擇了不適當的開發工具和設計工具而產生的複雜性。對於一個功能確定的程式來講，本質的複雜性是確定的，而非本質的複雜性則是沒有限制的。因此，一個應用的開發要想較順利地取得成功，就需要儘可能地減少非本質的複雜性。

　　OOD的特點

　　物件導向的設計（OOD）將一個程式分解成根據具體的對象而設計的一系列元素。這些具體對象的行為和資料以一種叫做“類（class）”的編程單元進行打包。應用程式建立一個或多個這些類的例示，也稱為“對象（object）”。類的行為是通過建立對象之間的關係組合在一起的。

　　OOD允許開發人員用兩種主要的方法來控制複雜性的增加。第一，OOD定義嚴格的出口語義，這允許開發人員隱藏實現的細節，並且明確說明什麼方法是其它的對象可以訪問的。這個資訊隱藏使得可以對大部分的代碼進行修改而不影響其它的對象。

　　第二，OOD將對象之間的關係分為四類：繼承、包容、使用和協調。適當地使用這些關係可以大大減少應用開發過程中本質的和非本質的複雜性。如，繼承是產生物件導向設計中可再使用的主要因素。這個再使用性是通過代碼共用和多態性獲得的。這種再使用可以大大減少應用的本質的複雜性。包容允許一個類的使用者在使用包容器時忽略被包容的類（class）。這個簡化使設計者能夠大大減少應用的非本質的複雜性。

　　可視化介面在OOD方面的不足

　　許多程式都需要可視化介面，這些介面由對話方塊、選單、工具條等組成。這些可視化介面的增加會引進OOD設計的不足，使得一個好的物件導向的設計走向反面。可視化介面有三個屬性可能會給應用開發帶來麻煩。

　　第一，可視化介面提高了傳統的面向操作的拓撲結構。使用者產生介面事件，如開關按鍵和列表框選擇等，受到程式的一個模組的驅動並且用來對靜態資料進行操作。在設計中將這面向操作的拓撲結構同一個物件導向的設計混合在一起將導致對象之間的大量的雜合。

　　第二，使用者介面通常對於同樣的資訊經常會需要許多不同的顯示。如，一個客戶挑選清單框可以包含一個客戶的名字和電話號碼以及許多其它客戶的名字。

　　當使用者選擇某個特定的客戶後，他／她的名字和電話號碼及其它全部相關的資訊都會詳細地顯示出來。

　　除此之外，一個簡單的程式可能具有不同的使用者介面。如一個銀行賬戶系統有一個介面用於出納員來訪問賬戶平衡、存款和取款，而監督者的介面則包含另外的資訊並加上帳號管理的功能。這些不同的介面很容易導致類的擴充。

　　最後，可視化介面在整個設計階段還會進行較大的改變。這些改變包括完全重新安排使用者與系統的互動操作等。可視化介面的這些改變即使在最好的設計中也會增加應用開發的複雜性。

　　MVC彌補可視化介面/OOD的不足

　　模型／介面／控制器（Model／View／Controller，MVC）編程技術允許一個開發人員將一個可視化介面串連到一個物件導向的設計中，而同時還可以避免我們上面討論的幾個問題。MVC最初是為Smalltalk語言而設計的。MVC通過建立下面三個層將物件導向的設計與可視化介面分開：

　　模型（Model）：模型包含完成任務所需要的所有的行為和資料。模型一般由許多類組成並且使用物件導向的技術來建立滿足五個設計目標的程式。

　　介面（View）：一個介面就是一個程式的可視化元素，如對話方塊、選單、工具條等。介面顯示從模型中提供的資料，它並不控制資料或提供除顯示外的其它行為。一個單一的程式或模型一般有兩種介面行為。

　　控制器（Controller）：控制器將模型映射到介面中。控制器處理使用者的輸入，每個介面有一個控制器。它是一個接收使用者輸入、建立或修改適當的模型對象並且將修改在介面中體現出來的狀態機器。控制器在需要時還負責建立其它的介面和控制器。

　　控制器一直決定哪些介面和模型組件應該在某個給定的時刻是活動的，它一直負責接收和處理使用者的輸入，來自使用者輸入的任何變化都被從控制器送到模型。

　　介面從模型內的對象中顯示資料。這些對象的改變可以通過也可以不通過使用者的互動操作來完成。如：在一個Web瀏覽器中負責接收頁面的對象收集和裝配棧中的資訊，必須有某種方式來讓這些對象通知介面資料已經被改變了。在模型變化時有兩種方法來對介面進行更新。

　　在第一種方法中，介面可以告訴模型它正在監視哪些對象。當這些對象中有任何一個發生變化時，一個資訊就被發送給介面。介面接收這些資訊並且相應地進行更新。為了避免我們上面討論的不足，模型必須能夠不用修改就支援許多種不同的介面顯示。

　　第二個方法並不直接將介面串連到模型中，它的控制器負責在模型變化時更新介面。控制器通過對模型對象或觀察器方法進行監測來檢測模型中的變化。這個方法不用瞭解介面的模型知識，因此介面就變成是可以跨應用使用的。

　　使用MVC的優點

　　MVC通過以下三種方式消除與使用者介面和物件導向的設計有關的絕大部分困難：

　　第一，控制器通過一個狀態機器跟蹤和處理面向操作的使用者事件。這允許控制器在必要時建立和破壞來自模型的對象，並且將面向操作的拓撲結構與物件導向的設計隔離開來。這個隔離有助於防止物件導向的設計走向反面。

　　第二，MVC將使用者介面與物件導向的模型分開。這允許同樣的模型不用修改就可使用許多不同的介面顯示方式。除此之外，如果模型更新由控制器完成，那麼介面就可以跨應用再使用。

　　最後，MVC允許應用的使用者介面進行大的變化而不影響模型。每個使用者介面的變化將只需要對控制器進行修改，但是既然控制器包含很少的實際行為，它是很容易修改的。

　　物件導向的設計人員在將一個可視化介面添加到一個物件導向的設計中時必須非常小心，因為可視化介面的面向操作的拓撲結構可以大大增加設計的複雜性。

　　MVC設計允許一個開發人員將一個好的物件導向的設計與使用者介面隔離開來，允許在同樣的模型中容易地使用多個介面，並且允許在實現階段對介面作大的修改而不需要對相應的模型進行修改。