復雜性
復雜性是應用開發過程中最令人頭疼的一個問題。每當在一個應用中增加一個功能時，它的復雜性通常呈幾何級的增長。這種復雜性往往導致程序的開發無法再繼續下去。這也是現在為什麼許多應用只有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浏覽器中負責接收頁面的對象收集和裝配棧中的信息，必須有某種方式來讓這些對象通知界面數據已經被改變了。在模型變化時有兩種方法來對界面進行更新。
