一、什么是軟件設計？

關于“什么是軟件設計”這樣一個問題，Jack W.Reeves 于14年前（1992年），就在其撰寫的論文——《What is Software Design》中給出了其個人觀點——“源代碼就是設計”。這一思想將軟件工程活動與傳統的工程活動區分開來，傳統的工程活動中設計過程中產生的僅僅只是設計文檔，構建過程完全依賴于設計文檔；而軟件的設計活動將源代碼的編寫也包含了進來，其不僅僅只是生產文檔。

這一理論聽起來似乎有些抽象，不妨來個類比：建筑設計行業中，建筑設計圖的最終完成標識了設計過程的終結，但是軟件設計過程能夠用軟件設計文檔的完成作為其結束標識嗎？顯然這是一個不可能的答案。軟件設計的復雜性與不確定性我想大家都深有體會，很多時候文檔與代碼之間的修改是一個反復的過程。因為需求分析階段中我們不可能全部得到客戶心里真正想要的是什么東西。即使知道客戶想要的是什么，同時也得隨時準備應付客戶不斷變化的新的要求。這是一場殘酷的戰爭，戰爭沒有結束的時候誰也不能確信他就是真正的贏者。

這一理論回答了“軟件開發者就是工程師嗎？”這一問題，揭示了編程與程序之間的關系：編程不是構建軟件，而是軟件設計。它將編碼這一階段包含在軟件設計過程中，同時又強調了頂層設計的重要性。

從這一理論出發，去思考軟件開發的幾個模型，我們會很清晰地理解以文檔驅動為核心的瀑布模型在當今開發過程中存在的先天不足和后天失調，它體現出來的優點就是嚴格控制的自頂向下的流程化工程思想。再看以面向對象為指導思想的噴泉模型，它強調的是無間隙、迭代化開發，其重點不再是設計文檔，而是如何面對復雜可變的現實環境。軟件設計是一個反復的迭代的過程，就目前來講還看不到“銀彈”的希望。

二、軟件危機與軟件質量：

“軟件危機”的提出使得人們開始對軟件及其特性進行更深一步研究，概括地來講就是解決這兩個方面的內容：如何開發軟件，怎樣滿足對軟件日益增長的需求；如何維護數量不斷膨脹的已有軟件。

面對“軟件危機”，與程序設計方法學密切相關的軟件工程在1968年應運而生。軟件工程研究的內容主要包括：軟件質量保證和質量評價；軟件研制和維護的方法、工具、文檔；用戶界面的設計以及軟件管理等。就如何保證軟件質量問題，各國軟件界都給予了廣泛關注與研究。國際標準化組織于2001年重新制定的ISO/IEC 9126標準，為保證軟件質量、評估軟件質量提供了依據。

ISO/IEC 9126軟件質量模型分為三層：特性、子特性和度量。軟件質量是特性的函數，每一特性又由一些子特性來衡量，而每一子特性又由一些定量化指標的度量來描述。按照影響軟件質量的各特性之間覆蓋最小的原則，可以將軟件質量分為六個特性：功能性、可靠性、易用性、效率、可維護性和可移植性。

三、面向對象軟件設計原則：

軟件設計的目標就是如何實現及保證軟件質量，我們評估軟件設計的好壞也就是通過軟件質量的六個特性作為依據。為了順利實現及保證軟件質量，業界經過幾十年的發展與積累，逐漸形成了開發過程中應遵從的原則。下面是面向對象軟件設計過程中最常用的5個原則：

A．單一職責原則：

一個類應該有且只有一個改變的理由。也就是解決職責不清的問題，通俗地講，既當爹又當媽這種行為用在軟件設計中是不可取的。采用這一原則進行設計的最大好處是提高軟件的可靠性與可維護性。

B．開放—封閉原則：

在不用修改原有類的基礎上就能擴展一個類的行為。如何正確理解“開放與封閉”，其對誰“開放”對誰“封閉”？這是我們理解這一原則的最大困難之處。它強調的重點在于“對于擴展它是開放的，對于修改它是封閉的”，其實也就是隔離變化，既達到職責單一又達到了擴展的目的。

C．替換原則：

派生類要與其基類自相容。也就是說“子類型必須能夠替換掉它們的基類型”。這一原則其實是對OCP原則的擴展，它強調的重點其實就是“父為子綱”。沒有父親也就沒兒子，這種繼承關系始終如一，不得改變。這一常理在這一原則中倒是得到了很好的體現。

D．依賴倒置原則：

依賴于抽象而不是實現。還有一種說法：抽象不應該依賴于細節，細節應該依賴于抽象。就我個人的觀點來講，我不喜歡后面這種說法。它不簡潔也容易讓人誤解。誰的抽象誰的細節？順藤摸瓜，瓜是抽象，藤是細節。其實這里面包含了歸納的思想，那就是從細節上抽象出其本質的東西。我們依賴的就是這個抽象本質，而不是它的具體實現細節。這又回到我上一原則所講的“父為子綱”。

E．接口隔離原則：

客戶只要關注它們所需的接口。說得明白一點就是，“不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結構”。如果我們把接口理解成角色，一個接口只是代表一個角色，每個角色都有它特定的一個接口，每個角色都服務于其客戶端對象。那么用“投其所好”這個成語來形容這一原則，我覺得再恰當不過。雖然其意含貶義，但是它定制化服務、個性化服務則值得我們學習。這一原則強調了對軟件實體通信之間的限制，它限制了通信的寬度，同時提供了一個指導化的設計思想，就是說通信要盡可能的窄，只投其所好。遵從這一原則帶給我們的好處是：在軟件系統功能需要擴展時，其修改的壓力會最小。

總之，關于軟件設計這樣一個課題，要思考與研究的東西實在很多，不只是哪一個人的事情。