nora 解釋的很清楚.... 我在舉個例子說明一下

不知道什麼是物件導向 其實滿正常的 因為我看過很多的工程師
寫了很多年 java 也頂多只是用 java 在寫 c 而已 ...
搞不太清楚什麼是物件導向

物件導向 並不僅僅是 封裝 繼承 多型 ...
物件導向其實就只是一種思維 ...
簡單的講就是 everything is object ...
所面臨的問題要用物件的角度來思考 ..
透過物件與物件彼此之間的互動 ..
來處理程序

這樣講可能有點抽象... 舉個簡單的範例 ..

假設今天要寫一個計算機 ...處理使用者的輸入 "1+2"
過去的寫法可能是
{
string input = "1+2";
for(int i=0;i<input.length;i++){
   if(input=='+')return add(input[i-1],input[i+1]);
   if(input=='-')return sub(input[i-1],input[i+1]);
}
我把它簡寫成...
switch{
   '+' : return add(1,2);
   '-' : return sub(1,2);
}
就是說如果運算式中遇到 + - 符號 分別會做這件事情
這也就是過去的方法 用一個 main function 去驅動你的程式的流程　得到返回的結果

如果有了一點點物件的想法以後
可能會想到"1 "數字本身就是一個物件
這個物件應該是要具有 add 與 sub 的方法 {假設寫成Num(1) 這個物件}
數字本身可以透過add或sub返回另一個數字
所以可能會寫成 {這邊省略掉 每一個字元轉成對應物件的過程}
{
switch{
   '+' : return Num(1).add(Num(2));
   '-' : return Num(1).sub(Num(2));
}
}
這樣就比較像是 物件與物件之間的彼此合作

但是在深入一點想 +,- 本身也是一個物件 這個物件就是在處理 兩個數字物件的運算
也就是 有一種物件叫做 Operator(Num,Num) 裡面有一個方法  execute 他會回傳一個  Num 物件
所以可能會寫成 {這邊省略掉 每一個字元轉成對應物件的過程}
new AddOperator(Num(1),Num(2)).execute();
new SubOperator(Num(1),Num(2)).execute();

這邊可能會有點誤解..怎麼感覺又變回傳統的方法  add(x,x);
但是 AddOperator 中 execute 的方法可能是這樣寫的
{
Num execute(){ return Num(1).add(Num(2));}
}

但是如果再深深入一點想 本身 "1+2" 本身就是一個物件...
這個物件叫做 Expression
所以應該是要寫成　return new Expression("1+2").execute();
詳細的內容就不再寫了

不知道這樣的說明有沒有比較清楚一點點 ...

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

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

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

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

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

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

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

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

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

老實說我一直搞不清楚什麼是物件導向
倒是我喜歡寫一堆function

當我寫一隻程式一直重複需要執行這個程式的時候
我就會多寫一個function來呼叫傳回
這應該也是種物件導向的運用吧

其實程式寫多 也不用去管甚麼是物件導向

因為這個只是一個程式演化後 新增的"名詞"

不過就是原始的程式碼 繁雜又多

寫了上千上萬行以後 連自己要維護搞不好都會頭大

之後進化成有function 跟迴圈方便使用與維護

但是卻又少了些便利性跟複製修改性

可能第一個function是算 某個公式 但是隔天老闆說 公式要改

就又要動原始碼

於是程式又進化 把這些function 迴圈 屬性 包起來 變成所謂的物件

讓使用者不用管裡面的程式碼到底是甚麼 只要會叫用跟操控物件的屬性還有功能

物件都是可以動態複製跟產生 而不像以前都要用複製貼上 再修改細部內容

某天老闆說要改公式 透過物件 只要去繼承原本的物件 然後把function 直接覆蓋過去

或是產生一個新的function 這時候所有資源都能取用 只要維護新的function就好

而不必整隻程式都要拿來改

其實不用物件也能透過一堆迴圈跟Function做到一樣的功能 但是總是比較麻煩 要燃燒設計師的腦漿

透過物件化的標準操作 新手也能快速上手 (不用去看所有的 Souce 只要看 物件有哪些屬性跟方法可以使用)

如果真的要用簡單的方式講物件導向

我覺得就是把一個母體 切割成很多零件 像樂高一樣

然後這些零件 今天拼成飛機 明天可能部分零件拿去拼賽車 這樣

如果是以往的程式寫法 飛機就是飛機 要改成賽車 還要自己看過飛機的每個部分 才能決定怎樣拆卸下來 改成賽車

[Ailio 在  2011-12-30 10:26 AM 作了最後編輯]

我個人對物件導向的認知啦
就是以物件為思考的出發點
對於物件能做甚麼事情
和其他物件之間的關係

其實真的就是一種概念而已
話說
我覺得我工作寫的
大部分還是以物件和程序導向互相交錯吧
看方便還有習慣而已...@@

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

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

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

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

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

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

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

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

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

OOP、CLASS、METHOD、OBJECT
就小弟的了解物件導向以最生活化的例子
以組電腦來說
DRAM, CPU, 主機版,硬碟,營幕，等等所組成
每一個零件都是由很多家不同廠商做出來的，你 RAM 可選取很多種頻率的 DDR, DDR2, DDR3,其中又分很多廠商,CPU主機版等也是
你要組一台電腦並不需要先從做 DRAM 在做 CPU 等等的東西出來後在組，你可以買到這些東西後就組起來了
在 .Net 的世界中 Class 是包在 namespace 之中
一個 namespace 可以包含多個 Class 感覺就像主機版上可以分好幾個區塊，有CPU模組,DRAM模組,有擴充槽模組等等
METHOD:就有點像音效卡，顯示卡，usb3.0卡,電示卡等等，它們的功能在於讓電腦有各種的功能

接觸程式設計多年 我對物件導向也是半懂而已  
寫程式都只是依樣畫葫蘆

個人是覺得物件導向的重點觀念可能在於封裝跟重用 0.0
我要作一件事情，不需要真的知道他的細節是什麼，只要知道他能提供我要的東西
比如說上面提到的車門，我不用真的知道車門是怎麼組裝出來的，他如何做出開門、鎖門的功能
我只要知道我可能呼叫 door.open() 就可以把車門打開、呼叫 door.lock() 就可以把車門鎖上
細節就讓開發車門的 developer 去掌控，他只要告訴我我呼叫時他會給我什麼東西即可....

這是個人膚淺的看法，不過我自己初學物件導向時是以這個角度來解釋的.....@@

還有一個很重要的觀念：事件

在很多使用狀態下都會需要使用到"事件"
一樣以車來說
按喇叭 其實就是在"喇叭開關"-"按下去(Click)"的事件裡面去執行"發聲"的動作
如果你把"發聲"放在其他的動作就不對了，像"碰到(MouseOn)"、"按下放開後(Release)"

放對事件，這在物件導向是很重要的