什麼是類別(Class)？什麼是物件(Object)？

我又看到有人在問這個問題了…在某個論壇裡

這個問題就好比在問「先有雞？還是先有蛋？」般的問題樣的…玄之又玄，答案總是渾沌不明的…(我沒說類別是雞…物件是蛋喔，請不要用對偶句解讀。)

寫程式的路上，我一直很希望有人能和我討論此事，幾年前物件導向基礎出來的時候，這個問題真是討論的沸沸揚揚的，當然學術界有正確的說法，但我更喜歡看論壇裡的人用千奇百怪的譬喻方法來解釋(有些真的讓人發噱)…現在我就把我記憶中一些好的說法列舉出來，並且用我的意思來說吧。

1、如果說房子是物件，那麼設計藍圖就是類別。這是最常見的說法…我覺得修改一下會更貼切

設計師設計畫好藍圖，決定了房子要座北朝南、決定了要有幾個隔間…人就要照著藍圖來使用這件房子。這是最常見的解釋…

我想要修改一下上面的說法，房子是最大的物件；客廳、盥洗間這些隔間是房子裡的物件；馬桶、浴缸是盥洗間裡的物件；馬桶蓋是馬桶的物件，馬桶蓋上的螺絲是馬桶蓋的物件之一。
一如房子有房子的設計師、馬桶有馬桶的設計師。我們只是選擇這些物件放在他該放的地方，動線設計得好一些讓買這個房子的人好使用。我們比較像是空間設計師、裝潢師傅，form的使用者是那些買房子的人。
類別、物件用這樣的例子看來，物件要多大有多大、說多小有多小，房子.隔間.客廳.沙發.沙發裡的彈簧。類別只不過是分類出來，告訴空間設計師在裝潢廁所裡的物件時，不要去客廳那一類別找，因為你不會在客廳這個類別裡看到馬桶這個物件。
所以物件是類別、類別也是物件。

至於誰才是設計師呢？我再修改一下我自已的說法
比方說我要選功能好的馬桶，那也先選有上市的。對我而言(對使用Visual Studio的人而言)，微軟這個直營大賣場裡頭，那批工程師就是馬桶設計師，.NET Framework是所有商品的型錄…裡面也許就有不同功能的馬桶類別，我得依我的客戶要哪種功能來挑選，在微軟不定義新的類別下(不出新功能的馬桶)，我當然還是可以多花一點心力自已做個客製化的(自已定義新的類別)，也許我可以從微軟馬桶型錄裡，找一個貼近客戶需求的加以改造(用繼承的方式)，又或者自已發明，硬是把馬桶變成躺著也可以用。
所以就我裝潢者的角度來看，我可以只拿微軟型錄有的馬桶給客戶，也可以自已開發新式馬桶…在程式設計界裡我們分別叫這二種角色為「coder」和「programer」，目前我還是在coder的階段，因為微軟裡要馬桶有馬桶、要冰箱有冰箱，我真的想不出來一個家裡還有什麼要放的物件是微軟沒有的，你呢???

2、如果說餅乾是物件，那麼模型盒子就是類別。這是我覺得貼切的說法，但我還是要修改一下

把餅掉改成食物…如果食物是物件，那麼食譜就是類別…食譜提供步驟、還有每一種食材的烹調方式，每種食材也是可獨立出來的物件。中餐、西餐是一種分類；晚餐、早餐也是一種類別；點心裡的餅乾、蛋糕也是一種分類。
微軟工程師是寫食譜的人，他們將食譜分類並提供各個食材的標準烹調方式，開發「類別」這個物件，而我們要把這個物件當作「類別」，遵照他的方法、屬性…等模型，做出來的菜至少不難下嚥。
對微軟工程師來說，都嘛是物件，都是把腦中的想法給具體化；而在我們眼裡

3、如果說人是物件，那麼靈魂就是類別…恩，這個是有意思的說法，我想要驗證一下。

人的身體是物件，所以可以 dim 某物 as 人，這個時候這個「人」只有驅體，因為我還沒跟程式說這個人是怎樣的人，還沒給他靈魂啦。

所以我定義一下：
Public Class 人 {
//我要用public不用private，因為生孩子沒什麼好偷偷摸摸的。
//底下就是寫一下靈魂，你要定義的屬性有哪些
人的性格(BINARY)
人的智商(INT)
人的反應動作(STRING)
End Class

不過如果我只是dim 某物 as 人的話，可能會是鬼或是借屍還魂的人，因為還沒有實體，最好還是dim 某物 as new 人，讓他正常的從嬰兒新生，成為一個實體。然後我就可以下個「某物.智商=20000」，讓他的IQ破錶，或者下個「某物.反應動作.說話(“媽媽我肚子餓了”)」的命令。(那人的反應動作這個物件，還要寫個物件…)

好了…從這個例子我們可以知道，人是不能被定義的，定義的出來的話會很可怕…還有，從「dim 某物 as new 人」這句話裡，也只是在宣告「請『給』我一個新的物件」，真正「誕生」物件的，是發明應用伺服器的程式設計師…至於什麼類別什麼是物件…這個例子裡我倒是看不出端倪…但有趣且富人生哲理

4、我自已的例子，這個例子不好，只是因為我愛樂高。

一塊一塊長的短的樂高積木是物件，你拼出來的東西還是物件。但你要拼一隻大火龍之前，你不先給分類出來，你光找材料就找死了。
所以你買大火龍套組的時候，樂高就先幫你分好類了，他分類的方式有趣，是頭部一袋、身體一袋、腳又另外一袋的分了…你不高興的話可以全打散用長短分類、用顏色分類，但不管如何，結果都一樣。除非你拿那個套件拼一隻烏龜。
所以對我而言，FRAMEWORK是那個大火龍套組，類別不過是微軟的分類方式，我要組烏龜的時候就可以不要理他的分類法打掉重做，所以類別不過是分類的方式而已。所以物件多的時候自然會可以有自已的類別，而類別也是因為物件才產生的。分類的好處在於你可以思考利用現有的物件可以做什麼(或許反向思考，還少這個類別還少什麼)

所以先有雞還是先有蛋…類別和物件真的是母子關係嗎，誰是母呢…玄啊…
恩，這篇文章基本上對於寫程式沒什麼太大幫助，就是純綷的從「物件導向基礎」裡得到的人生觀。