> ==>發信人: renderer.bbs@ptt.cc (rendering), 信區: programming
> ※ 引述《tester.bbs@bbs.csie.ncu.edu.tw (try or test)》之銘言：
> : OO 在概念上是接近分散式處理的, 會強制降低不必要的 coupling , 因
> : 此在分析設計上有幫助.
> 啊 ~~~
> 小弟覺得 OO 跟分散式處理應該沒有直接相關耶
> : 這個 "非循序議題" 是有必要深入探討的.
> design 是強調 High-Cohesion & Low-Coupling 沒錯 尤其是 OOD
> 然而 coupling 的降低並非意味「非循序」
> 只能說 coupling 的降低 能有效簡化平行或分散式處理的處理工作
降低 coupling 就會減少複雜度使事情的分析簡化, 但也就是分散式處理
的原則. C++ 目前可以確定不是 Concurrent High Level Language.
但封裝, 訊息傳遞, 動態繫結等可以直觀為 software IC , 但她確實是
為了 non-sharable memory 的硬體架構而思考的.
訊息傳遞的收送與隨之而來的處理起動, 本來就是一種高階的同步機制,
這個機制在目前的 C++ 是不明顯的, 因為為了單機效率, 她是傳統高階
的 Call-return 實作, 但 RPC 就是跨機的.
> 讓 OO 歸 OO
> 讓 Thread 歸 Thread
目前的 OO compiler 不會用 thread 實現 object , 因為沒有語言的同
步機制性指述, 同時沒有效率. 但任何高階語言的同步處理部分都可由
外部的外加功能方塊配合 Thread/Process 環境來獲得同步或併行協助,
在此點上, OOP 的程式先天就有優勢, 因為她的分割獨立性較好. 這時
候的 OOP 學習與訓練, 甚至其成果程式在 threading 分散化時有將來
的優勢.
> 讓分散式歸分散式
> 感覺事情才能單純化
> 現今 OOA OOD 的書似乎也沒有提及 OO 帶有分散式的概念在裏頭
> (也許小弟書讀得不夠多 呵呵)
> OO 討論的似乎不是分散不分散的議題
問題的分析與規格設計是在有效與方便, 減少 coupling 就已經是好的
設計, 根本不必去強調分散式處理, 因為是單機還是分散多機那是實現
時的問題, 而 OOP 就因 object 已俱有 scalable 的特性.
對分散併行處理言, 現在的 OOP 是不足的. 但先天上, 她有潛在的將
來性, 也因此讓單機共用記憶體的使用者覺得她背了一個還用不上的硬
殼.
--
◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234