謝謝你的讚美，希望我能

導向-->想法，作法
物件導向，利用物件的想法，作法來寫程式

你講的是encapsulation 封裝的概念吧
以類別來說
亞里斯多德最早對類別下定義，魚類，鳥類等

而相同類別通常都有共享的"屬性"(property,field)，譬如說腳的數目。與共享的"行為"(method,behavior)飛，走，吃飯，說話等。

既然分出的類別 就有類別的仔細程度的劃分，像是自然類的 界門綱目科屬種
人類向下劃分黑人，白人，黃種人等
越往下區分，性質就會越特定，也會越來越詳細的描訴

你可以說黑人是個人類，但是人類不一定是黑人，因為黑人是人類的子類別，所以將黑人視為人類叫up casting，

既然有了類別，屬於這類別的"東西"就叫作物件，譬如說我是個人(物件)，我屬於人類(類別)

我有身高，體重的屬性，我會吃飯，說話等行為

我個人是在語法學到一個階段之後，才開始有一點感覺的
(從運算子多載那邊吧...)


我覺得OO的主要...步驟吧，是先針對介面寫程式，而不是針對實作。
例如用程序導向(c)寫個印表機，一開始就要把函數的參數規劃好，
不然後期會改的很辛苦，例如print_A4(Data d) 或是 print(Data d,int paper_type)
...之類的細節 (結構化程式設計)


用OOP的話，就是先把印表機切成好幾個小類別，
例如進紙匣、噴墨系統、資料串流...等，
然後規劃他們的互動和結構...

這部份如果規劃的不錯，改天你要寫台雷射印表機時，
只要把噴墨系統拿出來，把碳粉系統放進去，
再改一下外觀就可以了

因為物件和物件之間不會管對方的實作，而是用介面溝通，
譬如說碳粉系統不會管進紙匣是哪一種，反正有紙會送來就對了，

也就是說OOP是在比較抽象的地方來作規劃

也有人把這些常用的、經典的物件結構、互動方式整理出來，
變成一種可以重用的經驗，就叫做design pattern

物件導向就在下所瞭解的粗淺概念是
就如同拼樂高積木一樣
古早寫程式需要先設計積木的零件，再將積木組合在一起
寫另一套程式時，還要重新設計一次零件，非常浪費時間

而物件導向語言是直接幫你把積木零件準備好
你只要將零件裝起來就可以了，不用再辛辛苦苦設計零件
更棒的是，之前用零件組合過的東西，還可以拿到下一次使用
譬如第一次用樂高組一棟公寓，裡頭還有車子、樹、游泳池、小公園
下一次改作透天別墅時，車子、樹、游泳池、小公園可以不用拆掉，繼續拿來用
甚至連公寓的牆、屋頂都可以移給別墅用，省去很多時間

所寫的程式重覆利用率越高，就越有物件導向的精神
如果程式寫得再好，但若不能拿到下一次開發程式時使用
就物件導向的概念來說，這仍然是個失敗的作品

我覺得相比Object Oriented, Interface Oriented倒是更難理解一些。

不太理解的話..
那多學習寫寫吧..
記得變數,方法,類別命名要正確..
每次看到那種命名不正確的..
我真的快吐血了...
有興趣的話..
乾脆連註解一起學習寫好了..
以前我們老師還要殘忍的要我們畫UML.....

物件導向是一種重要觀念, 而不是必要的手段

看過一些open source大計劃, 太過強調於物件導向設計, 物件與介面切割的太徹底了, 導致可讀性很低, 更怪的是與舊版的相容度也很低 (譬如其他使用其功能的application, 只能使用那某個版本, 要是使用新版都會出問題)

一些侯捷翻譯的物件導向書籍, 已經到了走火入魔的程度, 就算那些物件導向功能在強, 要是使用了卻沒人看的懂(往往合作團隊大多人都不太懂物件), 那到底是該用還是不該用呢, 用了也沒其他人有能力維護? 使用了不就是本末倒置嗎?
可以看看"人月神話"這本必讀書籍

linux kernel到了百萬行的等級, 也沒使用物件導向, 卻模組切割得很好, 很容易讀懂, 也很好維護

個人傾向是物件要懂, UML之類的東西也要玩過
但最重要的還是偏實戰非理論的軟體工程, 軟體模組化的設計與規劃, 程式撰寫技巧, interface設計與如何debug等

物件導向有點類似軟體ic的概念，就是說你不需要知道這個物件的原理是什麼，只要知道這個物件的行為，可以做什麼??再來就類似在做電路設計，將產品開發出來而已，基本上要配合UML塑模，將你要寫的程式的流程、物件的行為都具體化後再做設計...