結構化設計歷來備受責備的就是需求和設計之間的鴻溝，以前不是很理解這個鴻溝的原因�，F在再看，在結構化設計中模塊和模塊之間的關系，被緊緊局限于信息流，這限制了對模塊之間眾多關系的表達，也無法體現模塊和模塊之間其他的眾多關系，包含各種各樣的結構、行為、依賴、包含（在結構化設計中這種關系隱含在分層中）、繼承、關聯關系等等。它僅僅解決了模塊在封裝和信息隱藏方面的問題。
再看面向對象設計方法，充分挖掘了“關系”的表達方式，可以盡可能的將事物之間復雜的關系予以體現，而這些關系是實現設計的關鍵�？梢赃@樣比喻目前為什么面向對象方法如此流行，記得小時候經常在各種雜志上看到許多這樣的圖畫“一個鋼球，從高處落下，擊中某個翹起的裝置，裝置受到鋼球的沖擊，另一端抬起后，原來被截斷的水流開始流通，并引發另一個設備開始工作……，最終在另一端的某個蠟燭被點燃”。這就是在工業時代，眾多人被機械設計的靈巧和創意所深深吸引的其中一份圖畫。姑且不論這樣的裝置是否有實用價值，但它肯定帶給構思者無限的快樂和想象力，以至于當時經�？梢钥吹礁鞣N各樣這樣的圖畫。而面向對象的方法正是因使用對象的概念讓設計更接近于上面的各種設備，而讓機械設計時代的瘋狂和無盡的創造力進入了軟件工程師的視野。由于能夠充分表達事物之間各種各樣的關系（更接近于結構和行為方面），面對對象設計方法在今天創造了一個奇跡，各式各樣巧妙的設計實現、設計模式的流行，幾乎在永無止境的激發著愛好設計的人們的想象力和創造力。再看最流行的類比：建筑和軟件。建筑最主要的特征是什么——結構。這也是為什么建筑能夠和軟件設計（最終設計都要體現在模塊上）進行類比的潛在原因。相比之下，我更傾向于拿機械設計來和軟件設計進行類比。
回到結構設計化方法上來，雖然很多人都說結構化設計和面向對象設計沒有本質上的區別，那是因為某些關系依然可以通過轉換映射到信息流上，但這畢竟繞了一個大彎，而且由于缺乏足夠的表達各種關系的能力，極大的限制了軟件設計者的想象力和創造力。結構化設計方法使用自頂向下的手段，通過Process的逐層分解來理解和構建系統，然后把Process分配給模塊，這里的“分配”這幾乎讓每一個初次接觸結構化設計方法的人大惑不解，似乎模塊是Process分解的結果，甚至在如果已知了某些模塊時又直接將模塊映射成一個黑盒的Process，Process和模塊究竟是什么關系？沿著這個思路，很容易陷進“雞生蛋，蛋生雞”的困境。而事實是，模塊和Process的誕生，兩者之間根本沒有任何關聯，都是獨自根據經驗所產生的。為什么會產生這樣的問題？究其原因，結構化設計方法和我們自出生以來認識事物的方式有著很大的不同。因為打我們一出生，眼里落入的就是各式各樣的實體，而我們區分它們主要依靠就是事物各式各樣的特征，包括事物不同的結構和特定的行為，而結構化設計方法試圖通過信息流及其轉換來認識系統，這天生造成了某種障礙。相比之下，面向對象方法則和我們所熟悉的認識世界的方式相吻合，更加的自然。
那么結構化設計的優點到底是什么呢？考慮警察破案時，需要根據證人不斷的描述犯罪嫌疑人特征對犯罪嫌疑人進行畫像的場景，就可以理解結構化設計方法優點在于：當我們面對一個只知道存在各式各樣需求，而對系統其它方面一無所知的時候，它可以通過“功能”幫助我們逐步理清需求之間復雜的關系，它天生就有對需求之間重復功能進行匯聚的能力，通過對系統的需求的整體理解，讓我們知道系統到底需要做些什么，從而對系統有更清楚的認識，對“需求”的理解和澄清是結構化方法的核心。這樣也可以理解為什么結構化設計方法比面向對象設計方法更早的誕生。因為在軟件工業的早期，軟件系統彼此獨立，數量稀少，可以利用的經驗非常缺乏，而結構化設計方法則在這種一開始就缺乏經驗的時候有著極大的幫助，幫助人們從需求、功能的角度分析和理解系統。
那么，在我們理解結構化設計和面向對象設計的背后，到底隱藏了什么樣的秘密，又如何理解其他各式各樣的設計方法呢？其實，這個秘密躲藏在我們經常談起的“差異性”的背后。我們經常談起差異性，但卻很容易忽視和差異性相伴相生的另一面——“共同性”。共同性促使我們對事物進行分類和總結，而差異性則讓世界充滿了變化，并讓這個世界變得更加的復雜而樸素迷離。每一種“共同性”凝聚成一個軸，構成了我們觀察世界的“維度”。各種“維度”交織在一起，讓整個世界系統變成了一個復雜的“立方體”，這個立方體既不是平面的，也不是三維的，而是一個多維交織的復雜事物。結構化設計方法，抓住了“信息流”和“信息流轉換”兩個維度，并試圖沿著這兩個維度理解和認識系統；而面向對象設計方法則采用了“結構、行為”這兩個主要的維度（還有其他），引領我們看清世界。每一種方法都試圖通過某一個維度或者某幾個維度的組合，去幫助我們認識和理解世界，比如面向方面的設計方法、面向服務的設計方法等等。這樣再去理解表達方式，當某種表達方式能夠表達的維度越多，它所能適應的范圍就越廣，這樣也可以理解為什么目前很多的設計方法，都依靠的是UML，導致大家看不清其和面向對象方法存在的本質區別，也解釋了為什么結構化設計方法的表達方式其實限制了我們的想象力和創造力。其實面向對象方法也有其局限性，簡單的舉例，比如模板編程就抓住了算法結構的緯度。
沿著維度的概念，我們也可以看清楚Java和C＃以及C++本身的區別，也可以想象如果Java始終局限于純面向對象語言的偏執中，很有可能在通用語言的競賽中落后。再看動態語言Python，拋棄“類型”的維度，只抓住“名字”的維度，帶來的極大靈活性，它不需要判斷對象的其他維度的特征，只需要有一個相同的名字，程序就可以執行，當然也帶來了隱患，但如果認識不到這個維度的差別，很可能將會將這種語言特性，和面向對象語言中的“接口”（專注結構和行為）概念相混淆。其實，“共同性”所
文章來源于領測軟件測試網 http://www.kjueaiud.com/