swimman
|
發表於 2005-3-12 03:33 AM |
現在OO並不是主流了
現在講究的是component base programming了(當然還是用OO)
而且component也流行到了com+而不是舊的com model
最大的差別是com靠的是介面契約,東西會放在REGISTRY
而com+靠的是metadata可以在執行期利用reflection得知元件介面
而且可以允許不同版本的元件並存
最重要的是微軟全力推了十年的com現在也被他們自己踢進了垃圾桶
現在微軟全力再推.net架構
回歸到主題寫程式是一種專業，不會有瞬間暴增一甲子功力的事
| |
Acute
|
發表於 2005-3-8 11:24 PM |
引用: Vic寫到:
引用: Acute寫到:
問題1:
更改? 除非那個Object 有bug... 不然, 不應該是去更改, 而是繼承下來, 然後把某些功能置換成你要的
這也就是維護性問題, 試想, 當結構化程式設計時代, 因為某個function 不合用, 所以把他改掉了, 這時候, 問題來了, 其他使用到該function 的程式, 通通出問題了, 大家一起改... 改到死
so, 使用物件, 必須拋棄以前的觀念, 不應該去更改一個運作正常的物件, 因為更改動作, 將導致其他已經使用該物件的程式造成問題, 而是去繼承他, 然後加上你要的東西, 讓他變成另一個物件
問題2:
我不知道所謂應該粉簡單, 卻弄的粉麻煩是指啥...
不過... OO 的確有overhead, 這是跑不掉的, OO 之所以能夠發展, 憑借的是硬體越跑越快, OO 之所以必要發展, 是因為軟體越來越複雜, 如果不採用OO 的觀念, 舊系統的維護以及新系統的開發都越來越困難.
OO 並不見得讓程式變得簡單, OO 重點在於: 資源可重複使用(也就是一般稱為物件可重用性), 維護可靠性 (前面說的, 物件應該去繼承衍生, 不應該去修改他, 除非有bug), 資料隱密性 (這兒並非說物件內容要隱瞞啥, 而是指, 你不用知道該物件是怎樣寫的, 你只要知道如何使用他)
Acute.
這回你說對了~ 小神童~ OO的確是以繼承來做到符合要求~ 這我說錯了~ 
而的確... OO 並不見得讓程式變得簡單...這對我們這種只會偷懶的人來說~並不是好事～ 
不過只要有別人寫好又合用的class....那就不同~ 
老是寫錯字, 而且一錯就是三個字, 該打 
OO 的出發點, 物件重複利用本來就是其中一環
當然, 制定一個好的物件的確很辛苦
可是使用該物件時, 卻可以很輕鬆
所以, 把時間花費在建立一個好的物件是值得的
因為將來重複使用時, 就把時間省回來了 
Acute.
| |
Acute
|
發表於 2005-3-8 11:16 PM |
引用: 南無寫到:
今天看完第二章,對這一章節有一點疑惑
GDT.EIP.IDTR.NMI是用於何處,目的為何 
是否能為小弟解惑一下
你怎麼把一堆不相關的縮寫放一起 
EIP 應該是程式指位暫存器(Instruction pointer), 本來是IP 後來x86 CPU 由16 bits 轉32 bits, 所有32 bits register 都加上一個E, 變成EIP
NMI 這個是一個硬體名詞, 中文翻譯是: 不可遮罩插斷 (None Mask Interrupt)
GDT 英文全寫是:Global Descriptor Table, 這是386 開始, 因應CPU 出現protect mode 而多的名詞
IDT 英文全寫是:Interrupt Descriptor Table, 也是386 protect Mode 底下的名詞.
這些東西.... 你真想知道, 找組合語言的書來看, 你就知道了, 呵呵, 或者找以前談x86 CPU protect Mode 的書, 也都會詳細解釋.
Acute.
| |
Acute
|
發表於 2005-3-8 11:03 PM |
引用:
這篇貼這兒應該是正確的
這兒比較算是程式討論區... ^^"
ED 算軟體, 但是ED 的問題不放軟體求助區
so, 討論程式的書, 也不應該放讀書會才對 ^^"
Acute.
| |
Vic
|
發表於 2005-3-8 10:37 PM |
引用: Acute寫到:
問題1:
更改? 除非那個Object 有bug... 不然. 不應該是去更改, 而是繼承下來, 然後把某些功能置換成你要的
這也就是維護性問題, 試想, 當結構化程式設計時代, 因為某個function 不合用, 所以把他改掉了, 這時候, 問題來了, 其他使用到該function 的程式, 通通出問題了, 大家一起改... 改到死
so, 那用物件, 必須拋棄以前的觀念, 不應該去更改一個運作正常的物件, 因為更改動作, 將導致其他已經使用該物件的程式造成問題, 而是去繼承他, 然後加上你要的東西, 讓他變成另一個物件
問題2:
我不知道所謂應該粉簡單, 卻弄的粉麻煩是指啥...
不過... OO 的確有overhead, 這hO跑不掉的, OO 之所以能夠發展, 憑借的是硬體越跑越快, OO 之所以必要發展, 是因為軟體越來越複雜, 如果不採用OO 的觀念, 舊系統的維護以及新系統的開發都越來越困難.
OO 並不見得讓程式變得簡單, OO 重點在於: 資源可重複使用(也就是一般稱為物件可重用性), 維護可靠性 (前面說的, 物件應該去繼承衍生, 不應該去修改他, 除非有bug), 資料隱密性 (這兒並非說物件內容要隱瞞啥, 而是指, 你不用知道該物件是怎樣寫的, 你只要知道如何使用他)
Acute.
這回你說對了~ 大毒王~ OO的確是以繼承來做到符合要求~ 這我說錯了~
而的確...OO 並不見得讓程式變得簡單...這對我們這種只會偷懶的人來說~並不是好事～
不過只要有別人寫好又合用的class....那就不同~
| |
南無
|
發表於 2005-3-8 10:25 PM |
今天看完第二章,對這一章節有一點疑惑
GDT.EIP.IDTR.NMI是用於何處,目的為何
是否能為小弟解惑一下
| |
ROACH
|
發表於 2005-3-8 10:14 PM |
|
|
Acute
|
發表於 2005-3-8 09:54 PM |
引用: Vic寫到:
OO是個很好的構想~ 如果世界每種object都被寫出來後....只要會用就可以~ ( 當然, 有需要時還是要做一些更改)
但OO有時候很麻煩~ 只為了弄個很簡單的功能~ 都要將之object化~ 簡簡單單的東西竟然要寫這麼多code才可以達到~
不過熊是新手啦~ 也許習慣後~ OO弄起來會很easy吧~ 
問題1:
更改? 除非那個Object 有bug... 不然, 不應該是去更改, 而是繼承下來, 然後把某些功能置換成你要的
這也就是維護性問題, 試想, 當結構化程式設計時代, 因為某個function 不合用, 所以把他改掉了, 這時候, 問題來了, 其他使用到該function 的程式, 通通出問題了, 大家一起改... 改到死
so, 使用物件, 必須拋棄以前的觀念, 不應該去更改一個運作正常的物件, 因為更改動作, 將導致其他已經使用該物件的程式造成問題, 而是去繼承他, 然後加上你要的東西, 讓他變成另一個物件
問題2:
我不知道所謂應該粉簡單, 卻弄的粉麻煩是指啥...
不過... OO 的確有overhead, 這是跑不掉的, OO 之所以能夠發展, 憑借的是硬體越跑越快, OO 之所以必要發展, 是因為軟體越來越複雜, 如果不採用OO 的觀念, 舊系統的維護以及新系統的開發都越來越困難.
OO 並不見得讓程式變得簡單, OO 重點在於: 資源可重複使用(也就是一般稱為物件可重用性), 維護可靠性 (前面說的, 物件應該去繼承衍生, 不應該去修改他, 除非有bug), 資料隱密性 (這兒並非說物件內容要隱瞞啥, 而是指, 你不用知道該物件是怎樣寫的, 你只要知道如何使用他)
問題3:
OO 需要的是累積資源, 這跟以前很像, 一個程式熟手, 經常性的把以前的程式碼找出來, 修改一番, 變成新的程式的需求. 只是因為結構化設計的關係, 總是需要想一下原來程式怎樣搞得, 現在得改成啥樣子, 修修補補, 難免產生蟲蟲.
在OO 的觀念下, 則變成, 如果原物件不盡適用, 沒關係, 原物件還是整個copy 過來, 然後繼承下來, 修掉想置換掉的部份, 變成一個新物件. 這樣子, 物件程式庫越來越龐大, 也越來越容易使用, 萬一某日忽然發現, 基礎物件有個小bug, 沒關係, 改掉該bug, 所有用到該物件的程式, 重新編譯後, 同樣的bug 通通改掉了, 一次OK!
Acute.
| |
Vic
|
發表於 2005-3-8 07:57 PM |
OO是個很好的構想~ 如果世界每種object都被寫出來後....只要會用就可以~ (當然, 有需要時還是要做一些更改)
但OO有時候很麻煩~ 只為了弄個很簡單的功能~ 都要將之object化~ 簡簡單單的東西竟然要寫這麼多code才可以達到~
不過熊是新手啦~ 也許習慣後~ OO弄起來會很easy吧~
| |
Acute
|
發表於 2005-3-8 05:36 PM |
@_@ 好長一篇... 真有耐心的敲...
覺得有些觀念似是而非... 不太會形容
我個人感覺是... 軟體抓錯... 真正憑借的是感覺
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.
| |
| 本主題回覆較多，請 點擊這裡 檢閱。 |
