本文是我和近來認識的高級程序員tony的談話內容整理而成
Tony他對程序設計的認識足以使我無地自容
Tony是個十分低調的人
不為重用也沒什麼名氣（我想他也不看重名氣）
設計好的程序是他最大的理想
《淺論設計》
nyra() & solo
tony ( )
引言
軟件的產生過程
大概可分為計劃
實現和維護三個部分
實現過程主要有四個工作
分析
設計
編碼
測試
本文主要討論設計工作的方法
設計的前提
分析需要（需求分析）是設計的前提
它為設計工作提供了目標和基礎
設計工作就是在分析產生
的目標和基礎之前找到一條合理的路線
假如目標和基礎都是明確的
那設計工作實際上就沒有了任何
意義
好比你要找一本書
如果你知道是什麼書（目標）
又知道圖書館在哪裡（基礎）
那麼設計工作
就只變成了知識的組合（把有關於圖書檢索的知識組合起來）
這時候設計工作就好比是中國的考試一樣
無聊
Tony說
何不寫個應試程序呢？
自動化的CASE工具可以幫助我們完成這些設計
設計工作的挑戰在於分析不可能得出一個清晰明確的目標
甚至不能知道現在的基礎是什麼樣的
在
為別人設計程序時（一些大客戶）
他們的要求通常三天一變
這種變化是計劃所不能企及的
也是對分析
的否定
同時也對設計的挑戰
另外
在很多情況下
我們
做為程序的實現人員都是無知的
我們對手中
的工具一知半解
對自己的水平過於自信
這些都很可能導致在分析的時候得出不正確的結果
不能知道現在
的基礎是什麼樣的
我們必須認同分析中這種不確定性
不能指望分析的結論是完美無缺的
設計的理念
沒有正確的設計理念
每一種設計方法或思想都試圖證明它是正確的
這種嘗試就像在證明兩條平行線永遠不相交一樣
任何一種設計方法都是有效的
但都有其局限性
只在特定的情況下有效
也不一定比其它的都好
關鍵是我們是否認同它
並把它當成公理來使用
面向對象是我們的公理
Tony和我達成了這種認同
這是我們談話的基礎也是核心內容
而這種認同基於以下的理由
）OO（Object Oriented)更接近人的思維方式
人思考問題時
概念是最基本的單位
這正是OO中對象所描述的
）OOD（Object Oriented Design)有非常好的支持
很熱門的東西總是有很多的支持者
比如UML
C++等
這使得OOD很容易
容易做也容易實現（變成代碼）
）最後
也是最不成理由的是我們喜歡常用它
習慣也許是最關鍵的因素
面向對象的設計層次
匯編語言也可以用做實現OOD的編碼工具
但是它位於OO的最低層
在為匯編語言所做的OOD中
連最基本的對象概念都要明確說明
OOD中由大到小
可分為三個層次
框架（framework)
模式(pattern)和成語(idiom)
它們從不同的抽象層次對設計的方法做出了說明
）框架
框架是一種成熟的設計思路
它著眼於設計的內容
即設計的主體部分
框架為設計指明方向
典型的框架有win
下的MFC
OWL
OpenClass等
它們通常很大
無所不包
使用框架可以明確設計的主體結構
雖然大多數框架都有實用性的類
比如MFC中CArchive類
但它們只能做為框架描述的工具
而不能做為應用的直接內容
它們可以做為應用的實現基礎卻不能直接使用
) 模式
模式是一系列類的組合方法
它著眼於概念的組織
即設計的枝節問題
它可以把框架的描述類有效的組合起來
產生類樹（群）
典型的模式在Gof的書中有詳細的描述
模式解決的是設計中如何走的問題
它可能解決走哪一條叉路的問題
也可能解決涉水還是搭橋的問題
它不能解決向什麼方向走的問題（這由框架決定）
不能解決走路還是坐車的問題（這由成語解決）
它是設計工作中比較常用的抽象層次
通常討論的設計問題都在這一層次上
）成語
成語是語言相關的
它指某一種程序設計語言中實現某些功能的習慣方案
它可以大到如何實現類
小到循環變量是i還是conter
成語的掌握程序通常說明了設計師對語言的功力
好的設計師不應在面對
訪問卻不能屬於
（C++中的friend
java中的內嵌）這樣有點復雜的問題就束手無策
設計的過程
設計沒有結束
也沒有開始
廣義來說整個軟件開發過程都彌漫著設計的成份
計劃或維護的任何想法都是設計的一部分或是影響設計的因素之一
反復設計和持續設計是必要的
也是不可避免的
設計應保證自己的可擴展性
設計的變化不應導致大量其它工作的無效
簡單的說就是應盡量設計可復用的代碼
減少專用代碼的比例
但這一條規則卻不只針對代碼
結語
成功的設計來自於實踐
卻不局限於實踐
設計的思想（我們不說靈感
因為靈感通常認為是神秘而不可琢磨的）來自於生活的
各個方面
只有真的熱愛並多方面的體驗生活才有多樣的思想
From:http://tw.wingwit.com/Article/program/Java/hx/201311/27103.html
