對這文章發表回應

從 OOP 學習物件導向(Object-oriented)觀念時，你就不太容易去對一些基本的 "術語 (terminology)"，下功夫來去 "參透" 其本質的意涵。例如，我雖然已經許久沒有教授基本物件觀念的課程，但在教授類別圖(Class Diagram)與物件圖(Object Diagram)時，多少就需要複習與說明什麼是類別，什麼又是物件。尤其，我最喜歡 "考" 程式設計的老手們，一個他們認為再基本與簡單不過的問題了： 物件是由誰誕生的？

嘿，如我預料，十個有九個回答：是由其所屬的類別誕生的。 是嗎？ 我再請他們反思一個問題： 到底類別與物件的區別是什麼？ 有人會回答：類別是死的；物件是活的。 這更有趣了，既然類別是死的，那麼，死的類別怎又能如何誕生出活的物件呢？

物件是有機的生命體，但類別卻不是，事實上，世界上根本就沒有 "類別" 這種有機體；而若是類別不是有機的生命體，那麼， 物件就絕對不可能是由其誕生的！

為何會有公司、部門、員工等類別？ 因為容易讓組織的層次分明，這是一種 "人工" 的分類；為什麼從狒狒的角度看人，就知道 "非我族類"？ 因為這就是一種與生俱來的 "本能"，沒有任何理由，是再自然不過、也不用說明的道理了。所以，將 "物件" 分門別類，可以是 "人為判斷"，也可能是一種再自然不過的 "本能"，沒有絕對的標準，要將物件歸為那一類，只能說，要將物件分屬為某一類，你要能作比較 "合理化" 的說明而已。

看似再簡單不過的問題，其實才真正是蘊含極為深奧的哲理，要能具體說明類別與物件的區別，這其實比想像得還困難。首先，你可必須先徹底思考，到底什麼是類別，為什麼需要有類別，要如何分類 ...等。關於類別，我會就我個人幾年來持續思考的體悟與認知，另外著文說明。"類別" 這個主題，絕對是在物件導向觀念中，最為關鍵的核心，因為，決定資訊系統因應需求變動而所能承受的震盪程度，取決於類別圖的設計，真正的軟體行家，如 Peter Coad 與 Martin Fowler，非常擅長將問題領域(Problem Domain)的概念(Concepts)，抽象(abstract)化並依其本質與特性 "分門別類"，具化並組成為軟體內部的靜態結構，得以支撐系統的穩定、彈性與延展度。

回歸主題，到底物件是由誰誕生的呢？
我們先看底下一行程式碼，試著想想看，這一行程式碼的意思是什麼。

 Employee e = new Employee();

我在某討論區看到有人是作類似這樣的解釋： 用 Employee "類別" 造出一個 "物件實體" e ，這樣的回答，其實仍與物件是由其所屬的類別所誕生的意思是一樣的。

"Thinking in Java" 一書中，起碼還作了比較合理的說明：
You must create all the objects (所有物件都必須由你建立)

那個 "你" 是程式設計者？ 我寧願作這樣的解釋：
程式設計者(Programmer)透過 new 關鍵字來要求「請給我一個新物件」。

既然是 "請"，也就代表了，程式設計者只是作宣告(Declare)而已，真正 "誕生" 物件者，其實就是 "系統"！，再說得白一點，就是應用伺服器(Application Server)，或者，我個人蠻喜歡用 "Container" 這個術語，來說明應用程式其實就是透過它來取得系統層次的服務(System-level services)，包括誕生物件等。

透過上述的說明，上面那一行程式碼比較合理的解釋應該像是這樣：
"個體(Instance) e 透過 new 關鍵字宣告，請系統(System)建立一個新物件，並將其分屬於 Employee 類別 (也就是具備了 Employee 類別所應有的 "本能")。"

至於 "Instance" 一詞，本質就是物件，國內一般書籍翻譯為 "實例"，我很不喜歡，覺得不自然，也不夠貼近英文原意；翻譯成 "個體" 或 "實體"，應該是比較恰當的，而個體代表的就是，一個個的物件是可以獨立運作、為有機的生命體，瞭解(know) "something" 以及做(do) "something"。

對了，"系統(System)" 這個字眼，若以比較 "擬人化" 的術語，那未，我覺得「駭客任務」電影中，那個 "母體(Martix)" 應該會是最佳的代名詞了。 :-)