| #1 : 2005-3-8 05:36 PM
全部回覆
|
 送花
(4)
 送出中...
|
|
|
@_@ 好長一篇... 真有耐心的敲...
覺得有些觀念似是而非... 不太會形容
我個人感覺是... 軟體抓錯... 真正憑借的是感覺
PC 上有很好的debug tool, 他可以去慢慢追
但是, 離開PC 的平台, 常常除錯是憑借感覺, 憑借自身對自己寫的程式的感覺, 然後只要能夠找出錯誤怎樣發生, 就自然知道錯誤發生在哪兒
當然... 這本書只是談"程式設計", so, 觀點總是由"人"出發
軟體是一個眾志成城的工作, 真正講究的, 根本不是怎樣去寫, 而是將來怎樣維護
思緒停留在程式怎樣寫, 那只是程式設計師等級的工作, 沒資格稱之為軟體工程師
軟體之所以稱之為"工程", 就是因為軟體的發展, 老早就進入需要採用"工程" 工法來設計的境界
程式語言從早期的非結構化 發展到講究結構化程式語言, 然後又從結構化程式語言進一步發展到物件導向化
這一路的發展, 都是配合軟體工程的需求, 講究的重點都是, 將來如何維護
其實寫程式很簡單, 在CPU 狂飆的境界下, 寫程式不會比吃飯喝湯困難
程式語言不斷演化, 都是著眼於維護, 維護一詞, 包含:
1. 新增功能時, 舊程式碼能盡量沿用
2. 有錯誤時, 能夠迅速解決且不引發新錯誤
3. 因應實際需要, 能快速修改符合需求
4. 開發新軟體時, 從前開發完成的資源能夠快速引用
曾經在另一篇文章中, 我有說到, C 跟C++ 的根本不同, 在於觀念, 而非語法, 其實就是上述原因.
C 是一個結構化程式語言, 寫一個C 的程式, 講究的是整個軟體工程如何模組化, 只要模組劃分的夠好, 所有參予者, 可以按照每個模組的定義, 獨立工作, 最後進行整合. 但是模組化觀念最終還是被淘汰, 因為, 模組定義常常不夠明確, 系統整合時才會發現出了問題, 其次, 模組在新開發案沿用過程, 難免需要修補, 造成重複使用過程需要耗費人力去維護/修改舊有模組
C++ 則是新的物件化觀念, 寫一個C++ 程式, 從物件著手, 先規劃出"好的物件", 然後才由這些物件去組合成對應模組, 進而變成一個軟體. 而物件化理論上比傳統結構化好的地方, 就是, 理論上, 一個"好的物件", 你可以不用理解他的細部結構, 你只要知道這個物件會完成怎樣行為, 就好了. 就好像你不用知道怎樣做一張桌子, 你會用桌子即可, 你不用會製造原子筆, 你只要會用就好了.
so, 一個C程式或者C++ 程式, 重點不是語法, 而是設計的出發點, 很多人用C++, 但是實際是在使用結構化程式設計的觀念, 這並沒有發揮C++ 的特性與優點. 這種程式, 我通常戲稱為, 只是穿著C++ 程式的外衣. 當然, Windows 環境中... 找不到"好的物件", MS 的MFC 是Windows platform 的標準application framework, 但是, 他卻是一個爛示範, Borland 公司這方面是比較好的, 可惜, 那些人待錯公司, 他們當初為Windows 推出的application framework 是OWL, 從物件導向的觀點去看, OWL 的物件比MFC 好太多了, 但是, Windows 終究是MS 設計的, MFC 想不變成標準都有困難... Borland 推的OWL 註定只能消失在歷史的洪流當中.....
Acute.
[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]
|
