RSS   



  可打印版本 | 推薦給朋友 | 訂閱主題 | 收藏主題 | 純文字版  


 


 
主題: [其他] [求助]到底何謂物件導向?   字型大小:||| 
nora
青銅驢友
等級: 11等級: 11等級: 11等級: 11


十週年紀念徽章(六級)  

今日心情

 . 積分: 230
 . 文章: 510
 . 收花: 2040 支
 . 送花: 3072 支
 . 比例: 1.51
 . 在線: 1434 小時
 . 瀏覽: 6085 頁
 . 註冊: 8006
 . 失蹤: 781
#1 : 2011-12-29 09:01 AM     全部回覆 引言回覆

其實那只是概念,它是從物件(主體-可小到每一個主體)為出發點上面的前輩們都說得很清楚,不要被語言限制住,那只是手段與方法來實現你的目的,由每個物件本身來思考事件及成員,每個物件能如何發揮自己的價值提供何種服務,要達成這種目標要有哪些成員,不屬於自己的部分就請別的物件來協助,整體上來說就是由下往上的思考模式。

過去的語言思考模式是由上而下的, main() 裡面控制流程,物件的世界,是將流程與服務分離,所以提供服務才是本身該做的思維,而控制流程的可以向不同的服務提供者要求提供服務,如此一來提供服務的物件可以專心更精進的提供快速準確有效的服務,
而流程控制者可以更專心地思考自己的運作模式,不同的流程控制者使用相同的物件來服務,將兩個以上的物件組合後(加入些許的流程)再加以封裝,賦予更簡便有效的服務就是元件了。

所以物件本身的思考應該只有專心做好自己的事,而元件的思考則是使用不同的物件來達成提供的服務,主控流程盡量使用元件來達成,如此才能達到最大重複使用。

以電子硬體來說,物件就像電晶體,二極體,電阻,電容。將這些東西略加組和封裝成一塊基板或IC 就是元件,將這些基板或IC 當成提供服務的對象來達成目的才是產品本身。

音響>電源,前置,後級,面板,調諧.......
前置>EQ,立體解碼.......
立體解碼->AC3,DTS ......

注意一點很重要的是思維,一定要由下而上,站在物件本身的角度看,所以不應該是做音響的要包山包海全部自己來,將來多出不同的立體解碼規格,買了元件加入後就可以很快地有新功能上市,用不同的型號,來做產品生命週期,提供不同需要的使用者。

很多人雖知道物件導向,但是傳統的教育思維模式還是會採用由上而下的思維,如此就無法達到物件導向的精髓。
其他書上所說的都是特性,不是目的。

物件導向思維可用的地方不只是程式語言,其實早在各行業中都有運用,只是沒特別注意罷了,最多的應該是建築業,企業管理也有,總之要想 "分為何而分,組為何而組,如何能更快的分,更容易的組,分離後更有效率更單純的做好份內的事,組合要如何更少的流程更安全的組合",這才是物件導向思維的精髓,否則一樣都可達到目的為何要用不同的思維對吧。

早年有本 物件導向雜誌,由高煥堂老師為首的一群人出版的,有興趣可以去舊書攤找找(1995-200X年之間),難得的好雜誌可惜市面好像不常見。



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
nora
青銅驢友
等級: 11等級: 11等級: 11等級: 11


十週年紀念徽章(六級)  

今日心情

 . 積分: 230
 . 文章: 510
 . 收花: 2040 支
 . 送花: 3072 支
 . 比例: 1.51
 . 在線: 1434 小時
 . 瀏覽: 6085 頁
 . 註冊: 8006
 . 失蹤: 781
#2 : 2011-12-31 09:43 PM     全部回覆 引言回覆

樓上的三位也沒說錯,因為都能達成目的,只是思維不同,差異是看事情的角度,

傳統的做法是先由流程下手,遇到什麼才要求什麼,有時還用 call back ,雖目的達到,但是事先的規劃上去無法做到比較完善,
所有的東西都在你個人腦袋哩,文件管理難做,因為每個人有自己的習慣邏輯,較難累積文件資產。

採取物件導向思維,是先從領域的知識下手,與流程無關,思考模式是領域知識內原有的東西,只是加以分析運用,每做一個物件即可使用固定的格式寫下,因為有固定的格式,所以有許多程式碼產生器可用,文件管理較容易做,文件資產容易累積,物件可以有系統的發展強化變形,繼承組合。

分析設計時,可提前看出問題所在,使用 UML 可使專案更模組化與詳細討論,同時 UML 可文件化。這些文件的產出,不再被程式語言所局限,而是相同的思維可輕易地使用不同的程式語言來達成。也因為將思維用固的共同的語言來表達,所以只要會 UML
就可以讓不懂程式語言的人,加入討論,找出盲點。

所以因為物件導向設計的思維,使得的後續很多的步驟不再是程式員的專利(包括程式員不熟悉的部分),測試人員也可提前加入討論,讓整個專案更能經過詳細的討論找出盲點解決。

如過程式是設計師只是程式設計師那你可以用傳統思維來達成即可。
如果不將自己定位程式設計師,而是總工程師,那就必須接受改變,使用不同的思維來思考。

很多人寫了20,30年的程式黑手很難跳脫黑手階段,因為思維被侷限了。如果不想當永遠的黑手,不要再被程式碼綁住,
而是學習不同的思考模式,將自己的角度放在不同的觀點上,程式碼只是實現目的的手段,但是別忘了目的不便手段可變。

所以物件導向可以用不同的程式語言來實現,c++,c#,vb,java 都是手段,不同的語言運用在不同的領域,使我們更容易達成目的。
我們應該學習方法,才能跨不同的領域來完成目的,而不是被領域侷限。如同學習(儒道釋)法而不是(儒道釋)教,等你一通就萬法皆通(程式語言),屆時放在腦袋裡的是方法而不是程式碼。

廢話一堆,總之 物件導向思維要從 領域知識下手,領域知識可由訪談(領域專家)中取得,然後找出領域中的物件,再加以分析,使用適合的(人員)語言來實現,進而達到目的。



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記

   

快速回覆
表情符號

更多 Smilies

字型大小 : |||      [完成後可按 Ctrl+Enter 發佈]        

溫馨提示:本區開放遊客瀏覽。
選項:
關閉 URL 識別    關閉 表情符號    關閉 Discuz! 代碼    使用個人簽名    接收新回覆信件通知
發表時自動複製內容   [立即複製] (IE only)


 



所在時區為 GMT+8, 現在時間是 2024-5-1 01:18 PM
清除 Cookies - 連絡我們 - TWed2k © 2001-2046 - 純文字版 - 說明
Discuz! 0.1 | Processed in 0.020943 second(s), 7 queries , Qzip disabled