隨著面向?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ù)雜性通常呈幾何級(jí)的增長(zhǎng)。這種復(fù)雜性往往導(dǎo)致程序的開發(fā)無法再繼續(xù)下去。這也是現(xiàn)在為什么許多應(yīng)用只有Beta版本而沒有正式版的原因。

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

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

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

　　第二，OOD將對(duì)象之間的關(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è)簡(jiǎn)化使設(shè)計(jì)者能夠大大減少應(yīng)用的非本質(zhì)的復(fù)雜性。

可視化接口在OOD方面的不足
　　許多程序都需要可視化接口，這些接口由對(duì)話框、選單、工具條等組成。這些可視化接口的增加會(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)并且用來對(duì)靜態(tài)的數(shù)據(jù)進(jìn)行操作。在設(shè)計(jì)中將這面向操作的拓?fù)浣Y(jié)構(gòu)同一個(gè)面向?qū)ο蟮脑O(shè)計(jì)混合在一起將導(dǎo)致對(duì)象之間的大量的雜合。

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

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

　　除此之外，一個(gè)簡(jiǎn)單的程序可能具有不同的用戶接口。如一個(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è)程序的可視化元素，如對(duì)話框、選單、工具條等。界面顯示從模型中提供的數(shù)據(jù)，它并不控制數(shù)據(jù)或提供除顯示外的其它行為。一個(gè)單一的程序或模型一般有兩種界面行為。

　　控制器（Controller）：控制器將模型映射到界面中?？刂破魈幚碛脩舻妮斎?，每個(gè)界面有一個(gè)控制器。它是一個(gè)接收用戶輸入、創(chuàng)建或修改適當(dāng)?shù)哪Ｐ蛯?duì)象并且將修改在界面中體現(xiàn)出來的狀態(tài)機(jī)?？刂破髟谛枰獣r(shí)還負(fù)責(zé)創(chuàng)建其它的界面和控制器。

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

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

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

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

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

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

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

　　最后，MVC允許應(yīng)用的用戶接口進(jìn)行大的變化而不影響模型。每個(gè)用戶接口的變化將只需要對(duì)控制器進(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)階段對(duì)接口作大的修改而不需要對(duì)相應(yīng)的模型進(jìn)行修改。