日月光華 -- SE精華區(qū)文章閱讀
--------------------------------------------------------------------------------
 發(fā)信人: Jove (死生契闊，與子相悅，執(zhí)子之手，與子偕老), 信區(qū): SE
標(biāo)  題: [zz]MVC減少編程復(fù)雜性 
發(fā)信站: 日月光華 (2003年04月20日21:16:03 星期天), 站內(nèi)信件

MVC減少編程復(fù)雜性 

　　隨著面向?qū)ο蟮恼Z言（如Java）的迅速發(fā)展和普及，越來越多的編程人員開始在應(yīng)
用開發(fā)中使用這些語言。然而原有的開發(fā)語 
言（即面向操作的開發(fā)語言如C＋＋等）在短時(shí)間內(nèi)還不可能退出歷史舞臺(tái)，因此現(xiàn)在就
出現(xiàn)了面向?qū)ο蟮恼Z言和傳統(tǒng)的面向操作的 
語言共存的局面。在設(shè)計(jì)應(yīng)用中同時(shí)使用兩類不同的語言（混合語言設(shè)計(jì)）比過去只使
用一類語言會(huì)帶來許多新的問題，其中復(fù)雜 
性就是混合語言設(shè)計(jì)中最經(jīng)常遇到的問題。下面我們探討混合語言設(shè)計(jì)中可能導(dǎo)致復(fù)雜
性增加的地方，以及如何減少以至消除這些 
復(fù)雜性。 

　　復(fù)雜性 

　　復(fù)雜性是應(yīng)用開發(fā)過程中最令人頭疼的一個(gè)問題。每當(dāng)在一個(gè)應(yīng)用中增加一個(gè)功能
時(shí)，它的復(fù)雜性通常呈幾何級的增長。這種 
復(fù)雜性往往導(dǎo)致程序的開發(fā)無法再繼續(xù)下去。這也是現(xiàn)在為什么許多應(yīng)用只有Beta版本
而沒有正式版的原因。 

　　專家將應(yīng)用開發(fā)過程產(chǎn)生的復(fù)雜性分為兩類，即非本質(zhì)的（accidental）和本質(zhì)的
（essential）。本質(zhì)的復(fù)雜性是對于解決目 
標(biāo)問題所必然產(chǎn)生的復(fù)雜性，非本質(zhì)的復(fù)雜性是由于選擇了不適當(dāng)?shù)拈_發(fā)工具和設(shè)計(jì)工
具而產(chǎn)生的復(fù)雜性。對于一個(gè)功能確定的程 
序來講，本質(zhì)的復(fù)雜性是確定的，而非本質(zhì)的復(fù)雜性則是沒有限制的。因此，一個(gè)應(yīng)用
的開發(fā)要想較順利地取得成功，就需要盡可 
能地減少非本質(zhì)的復(fù)雜性。 

　　OOD的特點(diǎn) 

　　面向?qū)ο蟮脑O(shè)計(jì)（OOD）將一個(gè)程序分解成根據(jù)具體的對象而設(shè)計(jì)的一系列元素。這
些具體對象的行為和數(shù)據(jù)以一種叫做“類 
（class）”的編程單元進(jìn)行打包。應(yīng)用程序創(chuàng)建一個(gè)或多個(gè)這些類的例示，也稱為“對
象（object）”。類的行為是通過創(chuàng)建對象 
之間的關(guān)系組合在一起的。 

　　OOD允許開發(fā)者用兩種主要的方法來控制復(fù)雜性的增加。第一，OOD定義嚴(yán)格的出口
語義，這允許開發(fā)者隱藏實(shí)現(xiàn)的細(xì)節(jié)，并且 
明確說明什么方法是其它的對象可以訪問的。這個(gè)信息隱藏使得可以對大部分的代碼進(jìn)
行修改而不影響其它的對象。 

　　第二，OOD將對象之間的關(guān)系分為四類：繼承、包容、使用和協(xié)調(diào)。適當(dāng)?shù)厥褂眠@些
關(guān)系可以大大減少應(yīng)用開發(fā)過程中本質(zhì)的和 
非本質(zhì)的復(fù)雜性。如，繼承是產(chǎn)生面向?qū)ο笤O(shè)計(jì)中可再使用的主要因素。這個(gè)再使用性
是通過代碼共享和多態(tài)性獲得的。這種再使 
用可以大大減少應(yīng)用的本質(zhì)的復(fù)雜性。包容允許一個(gè)類的用戶在使用包容器時(shí)忽略被包
容的類（class）。這個(gè)簡化使設(shè)計(jì)者能夠大 
大減少應(yīng)用的非本質(zhì)的復(fù)雜性。 

　　可視化接口在OOD方面的不足 

　　許多程序都需要可視化接口，這些接口由對話框、選單、工具條等組成。這些可視
化接口的增加會(huì)引進(jìn)OOD設(shè)計(jì)的不足，使得一 
個(gè)好的面向?qū)ο蟮脑O(shè)計(jì)走向反面。可視化接口有三個(gè)屬性可能會(huì)給應(yīng)用開發(fā)帶來麻煩。 

　　第一，可視化接口提高了傳統(tǒng)的面向操作的拓?fù)浣Y(jié)構(gòu)。用戶產(chǎn)生接口事件，如開關(guān)
按鍵和列表框選擇等，受到程序的一個(gè)模塊 
的驅(qū)動(dòng)并且用來對靜態(tài)的數(shù)據(jù)進(jìn)行操作。在設(shè)計(jì)中將這面向操作的拓?fù)浣Y(jié)構(gòu)同一個(gè)面向
對象的設(shè)計(jì)混合在一起將導(dǎo)致對象之間的大 
量的雜合。 

　　第二，用戶接口通常對于同樣的信息經(jīng)常會(huì)需要許多不同的顯示。如，一個(gè)客戶選
擇列表框可以包含一個(gè)客戶的名字和電話號(hào) 
碼以及許多其它客戶的名字。 

　　當(dāng)用戶選擇某個(gè)特定的客戶后，他／她的名字和電話號(hào)碼及其它全部相關(guān)的信息都
會(huì)詳細(xì)地顯示出來。 

　　除此之外，一個(gè)簡單的程序可能具有不同的用戶接口。如一個(gè)銀行賬戶系統(tǒng)有一個(gè)
接口用于出納員來訪問賬戶平衡、存款和取 
款，而監(jiān)督者的接口則包含另外的信息并加上賬號(hào)管理的功能。這些不同的接口很容易
導(dǎo)致類的擴(kuò)展。 

　　最后，可視化接口在整個(gè)設(shè)計(jì)階段還會(huì)進(jìn)行較大的改變。這些改變包括完全重新安
排用戶與系統(tǒng)的交互操作等。可視化接口的 
這些改變即使在最好的設(shè)計(jì)中也會(huì)增加應(yīng)用開發(fā)的復(fù)雜性。 

　　MVC彌補(bǔ)可視化接口/OOD的不足 

　　模型／界面／控制器（Model／View／Controller，MVC）編程技術(shù)允許一個(gè)開發(fā)者
將一個(gè)可視化接口連接到一個(gè)面向?qū)ο蟮脑O(shè) 
計(jì)中，而同時(shí)還可以避免我們上面討論的幾個(gè)問題。MVC最初是為Smalltalk語言而設(shè)計(jì)
的。MVC通過創(chuàng)建下面三個(gè)層將面向?qū)ο蟮脑O(shè) 
計(jì)與可視化接口分開： 

　　模型（Model）：模型包含完成任務(wù)所需要的所有的行為和數(shù)據(jù)。模型一般由許多類
組成并且使用面向?qū)ο蟮募夹g(shù)來創(chuàng)建滿足五 
個(gè)設(shè)計(jì)目標(biāo)的程序。 

　　界面（View）：一個(gè)界面就是一個(gè)程序的可視化元素，如對話框、選單、工具條等
。界面顯示從模型中提供的數(shù)據(jù)，它并不控 
制數(shù)據(jù)或提供除顯示外的其它行為。一個(gè)單一的程序或模型一般有兩種界面行為。 

　　控制器（Controller）：控制器將模型映射到界面中。控制器處理用戶的輸入，每
個(gè)界面有一個(gè)控制器。它是一個(gè)接收用戶輸 
入、創(chuàng)建或修改適當(dāng)?shù)哪Ｐ蛯ο蟛⑶覍⑿薷脑诮缑嬷畜w現(xiàn)出來的狀態(tài)機(jī)。控制器在需要
時(shí)還負(fù)責(zé)創(chuàng)建其它的界面和控制器。 

　　控制器一直決定哪些界面和模型組件應(yīng)該在某個(gè)給定的時(shí)刻是活動(dòng)的，它一直負(fù)責(zé)
接收和處理用戶的輸入，來自用戶輸入的任 
何變化都被從控制器送到模型。 

　　界面從模型內(nèi)的對象中顯示數(shù)據(jù)。這些對象的改變可以通過也可以不通過用戶的交
互操作來完成。如：在一個(gè)Web瀏覽器中負(fù)責(zé) 
接收頁面的對象收集和裝配棧中的信息，必須有某種方式來讓這些對象通知界面數(shù)據(jù)已
經(jīng)被改變了。在模型變化時(shí)有兩種方法來對 
界面進(jìn)行更新。 

　　在第一種方法中，界面可以告訴模型它正在監(jiān)視哪些對象。當(dāng)這些對象中有任何一
個(gè)發(fā)生變化時(shí)，一個(gè)信息就被發(fā)送給界面。 
界面接收這些信息并且相應(yīng)地進(jìn)行更新。為了避免我們上面討論的不足，模型必須能夠
不用修改就支持許多種不同的界面顯示。 

　　第二個(gè)方法并不直接將界面連接到模型中，它的控制器負(fù)責(zé)在模型變化時(shí)更新界面
。控制器通過對模型對象或觀察器方法進(jìn)行 
監(jiān)測來檢測模型中的變化。這個(gè)方法不用了解界面的模型知識(shí)，因此界面就變成是可以
跨應(yīng)用使用的。 

　　使用MVC的優(yōu)點(diǎn) 

　　MVC通過以下三種方式消除與用戶接口和面向?qū)ο蟮脑O(shè)計(jì)有關(guān)的絕大部分困難： 

　　第一，控制器通過一個(gè)狀態(tài)機(jī)跟蹤和處理面向操作的用戶事件。這允許控制器在必
要時(shí)創(chuàng)建和破壞來自模型的對象，并且將面 
向操作的拓?fù)浣Y(jié)構(gòu)與面向?qū)ο蟮脑O(shè)計(jì)隔離開來。這個(gè)隔離有助于防止面向?qū)ο蟮脑O(shè)計(jì)走
向反面。 

　　第二，MVC將用戶接口與面向?qū)ο蟮哪Ｐ头珠_。這允許同樣的模型不用修改就可使用
許多不同的界面顯示方式。除此之外，如果 
模型更新由控制器完成，那么界面就可以跨應(yīng)用再使用。 

　　最后，MVC允許應(yīng)用的用戶接口進(jìn)行大的變化而不影響模型。每個(gè)用戶接口的變化將
只需要對控制器進(jìn)行修改，但是既然控制器 
包含很少的實(shí)際行為，它是很容易修改的。 

　　面向?qū)ο蟮脑O(shè)計(jì)人員在將一個(gè)可視化接口添加到一個(gè)面向?qū)ο蟮脑O(shè)計(jì)中時(shí)必須非常
小心，因?yàn)榭梢暬涌诘拿嫦虿僮鞯耐負(fù)浣Y(jié) 
構(gòu)可以大大增加設(shè)計(jì)的復(fù)雜性。 

　　MVC設(shè)計(jì)允許一個(gè)開發(fā)者將一個(gè)好的面向?qū)ο蟮脑O(shè)計(jì)與用戶接口隔離開來，允許在同
樣的模型中容易地使用多個(gè)接口，并且允許 
在實(shí)現(xiàn)階段對接口作大的修改而不需要對相應(yīng)的模型進(jìn)行修改。 

--
"I'm not a great programmer; I'm just a good programmer with great habits".
                                                                 ---Kent Beck
※ 來源:·日月光華 bbs.fudan.edu.cn·[FROM: 10.85.38.144]

 

--------------------------------------------------------------------------------
[返回上一頁] [本討論區(qū)]