許多技術人員係從物件導向程式語言(OOP, Object-Oriented Programming Language)來學習物件導向，從 OOP 的角度來學習物件導向時，經常會把它當作是一種 “技術”，當作 “技術” 時，你會想去 “用” 它，而若當你無法 “應用” 在現實面時，就會覺得 “不好用”、”難用” 、理論無法與現實結合” …等。
把物件導向當作 “技術” 的最大的問題是：你永遠不知道為什麼你要使用物件導向！
幾年前，微軟的 COM 剛盛行時，有些是 “微軟技術代言人” 會在其技術文章裡提及：COM/3-tier/物件導向技術是增進系統效能(Performance)的最佳解決方案；採用上述提及的技術可以加速系統開發。甚至到現在，我仍常聽到：採用 EJB(Enterprise Java Bean) 是實現物件導向的最佳利器、可以讓開發者 “ReUse” 所設計的元件(Component)、節省開發者的開發時間。
嘿，這些 “似是而非” 的論調，幾年前從技術人員口中聽到是如此，現在聽到的還是如此，說真的，我是覺得，還真是一點自我的反思都沒有。我每次對這些技術人員的反駁就是：有什麼方式會比 Client/Server 直接連線至資料庫來處理還要快？ 有什麼開發方式會比你使用 Client/Server 拉一拉表單，然後直接至資料庫 “撈” 資料還要便捷？ 當然，技術人員的直覺反駁是，Client/Server 無法應付數百人以上同時間的交易處理，是啊，沒錯啊，Client/Server 有些假設點：同時上線使用者不超過 200 人、系統的需求不常變動。
但，重點是，系統效能與你採用 COM/EJB/物件導向有何關係？ 那是屬於系統資源(Resource) 的控管處理，諸如 Resource Pooling 的機制、Transaction Management(還包括交易物件的設計)的處理，Database “Performance Tunging”、頻寬的資料傳輸量的處理… 等。
而採用物件導向/COM/EJB 可以節省系統開發？ 那更是可笑！ 採物件導向可更是耗費開發成本，開發人員每當一想到為什麼要在中間層對物件分門別類，然後實做一個功能要串上好幾個物件的傳遞才能完成工作，一直無法接受這種觀念，如同 Martin Fowler 所提：你永遠無法讓物件導向的新手們瞭解為什麼要採取這種分散式的設計，你只能要求他們如此做，幾年後，他們會突然頓悟，腦袋有如重生一般。所以，採取物件導向可是要花腦筋在軟體設計上，而且若是實做在所謂的實體元件的機制，如 COM+/EJB，那是為了系統分散與交易機制的處理的元件規格，所以，實做上可是更為麻煩，一點也不會減輕開發者的實做的負擔。
所以，為什麼要使用物件導向？ 因為，物件導向是一種思維，是一種哲理，是一種典範，甚至是一種生活觀，你需要綜合相當多的知識，蘊化為 “智慧”，來協助你如何應付與應對軟體的 “善變”，並能提供具體的解決方案。嗯，這兩年突然對軟體設計某小一部分的哲理有一些 “頓悟” 後，每當看到許多系統因為粗製濫造而衍生出複雜的表象，眾多人們卻被淹沒在糾纏不清的問題與狀況時，而個人(外加 Ringle) 卻能 “一眼” 看出問題在哪裡，並且可以提出具體的解決方案，嘿，那可真是莫大的成就感與喜悅的呢。
學習物件導向的思維與哲理可是一條漫長之路。對我而言，我個人是已經選擇了這條 “自討苦吃” 之道，這條道路所要學習的廣度與深度，可是與圍棋之道一樣的深奧無比，每一個階段的學習與體悟，會讓你更接近與探索根本道理，但，似乎又永遠無法達到那個 “彼岸”。如同吳清源大師已經快 100 歲，仍舊每天研究圍棋；Ivar Jacobson 已經 80 餘 近 70歲，卻仍茲茲不倦地研究與發表軟體設計的論述一樣，這是終身職志，已經是融入每天的生活，永遠也研究不完的，甚至，還準備帶到下一輩子繼續來「修道」的。 😉
所以，回頭來看物件導向程式語言，OOP 僅是實現(Implement)物件導向的工具，你會想透過 Java, VB.NET 等程式語言來實作如介面(Interface)、繼承(Inheritance)、多型(Polymorphishm) …等設計。但問題是，OOP 無法告訴你 “What” and “Why” 介面、繼承、多型等這類屬於設計的哲理面(philosophy)，甚至，也無法告訴你 “What is Object?”、”How to divide the Object?” …，而這些哲理，根本不是為了重覆使用或增進效能，目的旨於，協助人們在面對複雜的現象時，應用 “本來就有” 的智慧哲理，來解決複雜的問題，而 OOP，是讓軟體人員解決問題時，所需使用使用到的 “工具”，它就是工具，就是一種手段而已！
從 OOP 學習物件導向觀念是一種本末倒置的方向，那不會是一個好方法，若勉強說，利用 OOP 來 “驗證” 物件導向的一些設計想法，那到說得過去。那麼，從何處學習物件導向呢？ 我這兩年，是透過 “觀察” 生活的週遭環境，逐漸來反思與體悟的。這與我多年來閱讀許多大量其它領域的書籍，除了軟體設計專業書籍外，包括學習類、成功潛能類、企管與專案管理、歷史 …等，實在有莫大的幫助，對短期的軟體技能幫助不多，但對中長期在軟體設計的思考上，會突然在某一個時間點突破而後 “頓悟”，這時再回頭看軟體專業各類的書籍，那可真是遊刃有餘，輕鬆而能感受書中的作者所想表達的觀點與主題。
對初學者，若要更具體一點，要看相關這方面的書籍的話，除了上次介紹過 Grady Booch 的「Object-Oriented Analysis and Design」一書外，國外的一些書籍，例如 James Martin/James J. Odell 合著 「Object-Oriented Methods」 一書，除了內容淺顯易懂、又饒富物件思維之道外，書籍排版與印刷的精美，那更值得典藏的好書。有件事最好避免，國內坊間 OOP 的書籍，有談及物件導向觀念的，最好略過不要看，幫助不大，反而誤導成分居多。
有感而發，既然，Java and .NET 都已經昭然若揭，程式語言確然往物件導向的實做之路，那麼，軟體人員也確實需要俱足物件導向的設計觀念。隨著工具的易學易用，以及網際網路龐大的資料庫，成為實做 “how-to” 的最佳參考來源，使得實做得以更形簡單。那麼，軟體人員更需要將精力擺在物件導向的設計思維，才有可能應對越形複雜的系統，懂得如何以簡御繁。
所以呢，我個人準備把我這幾年的一些心得與體會，儘量利用日常生活面的例子，來解釋物件導向的一些基本觀念與術語，例如，什麼是物件/類別、什麼是介面/多型、什麼是封裝 …等。我會將這些文章另行分類成 “物件基本觀”。對了，有一些議題我會採反問的方式來闡述一些個人的物件觀。例如，若你要問我，EJB 是不是物件導向？ 我會說 “不是”；然而 Client/Server 是否是物件導向？，我的答案卻是 “Yes”。 呵呵，先賣個關子，這些是蠻有趣也蠻引起爭議的話題，爾後我會著文說明我的看法與理由的。
您好 :
拜讀你的文章，感覺似有未盡，文中所提的兩本書 :
Grady Booch 的「Object-Oriented Analysis and Design」
James Martin/James J. Odell 合著 「Object-Oriented Methods」
小弟愚駑，似乎找不到正確的書籍，不知道是否可以提供書本的ISBN碼。
這裡： http://www.amazon.com/Object-Oriented-Methods-Foundation-UML-2nd/dp/0139055975
ISBN-10: 0139055975
ISBN-13: 978-0139055973
這是一本非常精緻的書，可以買來收藏。 🙂
另，您可以至 FB 社團： 軟體設計鮮思維
https://www.facebook.com/groups/softthinking/
其中檔案下載區有個人撰寫關於 物件導向入門觀念的簡報先行思考下。
感謝你的回覆，已經有購買到二手書。
之前一直看中文的網站或書籍，後來才發現好多觀念都被誤導，
有的網站自己甚至分不清楚 多載跟多型….
個人的想法分享 :
從程式實作的角度 :
物件導向技術其目的: 就是讓program即使有變化…亦不用大修改!!!
那麼到底如何變化…亦不用大修改呢?
背後思想就是運用 “抽象” !!
encapsulation, inheritance , interface , polymorphism , delegate 等等一切一切名詞,概念…. 都是來實現 “抽象“.
讓我舉一個例子,例如 polymorphism, 因為有了polymorphism ,
(以下取自http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming 留意粗體!)
{
var animals = new List() {
new Cat(“Missy”),
new Cat(“Mr. Mistoffelees”),
new Dog(“Lassie”)
};
foreach (var animal in animals) {
Console.WriteLine(animal.Name + “: ” + animal.Talk());
而不用 到 switch 來判斷 是甚麼動物. (不用 case cat then cat.Talk() )
正因為polymorphsim, 若遇到有新動物時,只需新增某種動物class 即可!
animal class 就是 狗class,貓class 的抽象….
interface, delegate..等等就是行為抽象…
一切一切都是因著”抽象”,來達到program即使有變化…亦不用大修改 !
謝謝! 有不同想法請告之!渴求討論!
非常非常好的見解與心得分享。 🙂
我與我的 partner Ringle 提及到您這篇的分享，他很認同。
不過，這也同時讓我思考，是否還有比 “抽象” 更 “抽象” 的層次呢？
可能我這幾年的心得，所思考出來的心得是，可能 “架構 (architecture)” 還來得比 “抽象” 再更抽象一些。 ^^
基於 “架構” 的整體性考量下，所需具備的能力就包括了 “抽象” 與 “聚焦” 等技能。
不過，”架構” 這個詞彙，可能被泛濫掉了。畢竟，越 “抽象” 的層次，越容易被 “各自表述”。 🙂
歡迎隨時保持交流討論喔。
您好:
看到你的文章，我感覺到某些同感，但又些微的跟我認知有差異。
先說明一下，我是寫嵌入式 linux的軟體工程師，因此，我開發的環境，是純C語言，那是個非OOP的程式語言，思維是「結構化」，但是到了現在，我反而趨向C語言，模擬OOP的方式做開發，但這個過程，思維的轉換仍然非常辛苦。
所以，我同意OOP是思維。
但，在這個轉換的過程，我發現了一個問題，我知道物件導向的思維，但我無法用C語言模擬此思維，但網路上確有OOPC這個C語言模擬物件的h檔文件(支持C99規範)。
搜尋了資工科系的相關資料，看了「軟體架構學」，作者:趙善忠，之後，我才恍然大悟。
原來，並非是知道OOPC是思維就能夠使用，能夠轉換，而是，如果無法讓你聯想到OOP思維，OOP反而就沒辦法使用。
但現今的資工科系也很少教學如何聯想到OOP思維，除「軟體架構學」此書外。所以我相信，就算知道OOP的人，UML也仍看不懂，不會用，但UML本身卻是為了OOP創造的「簡單型思維語言」。
所以我覺得，根本問題是軟體的教學應該是
1.軟體架構
2.程式語言
而非是
1.程式語言(軟體思維、軟體架構自己想)
跳過了軟體架構的思維當然覺得程式語言很難了，不明白OOP為什麼要使用了。
OOP 是表達運用所謂 “物件” 的設計分析思維的一種機制與工具，所以，若是不瞭解分析設計的目的(這可能很多人都沒去思考，以為只是想要快速的作出來)，那麼，有好的工具其實意義也不會太大。
所以，你可能誤解了 OOP 是思維，不是喔，我在文內應該表達的很明確：它只是工具，重點是你看待系統分析的設計角度與思考核心是甚麼(更甚者，還要能擴展至團隊成為共識)。
再則，該本趙教授出版的書，我大致有翻閱過。我是以為，趙教授所解釋的軟體架構是比較偏向軟體結構。 Architecture 與 Structure 的意涵可是大大的完全不相同也不能去對比的。
我還是再次強調，所謂物件導向的思維，並不會是純用技術面去看待它的。^^
hey,不好意思
抓個小錯誤,從 wikipedia來看
Jacobson似乎才剛滿70歲耶…
http://en.wikipedia.org/wiki/Ivar_Jacobson
您的文章指出「他已經八十餘歲」
還是說我們指的是不同人嗎??
哇！！ 我竟然給大師虛加了 10 來歲，實在大不敬！！
感謝您細心的糾正。 !^^
Hi James:
對耶，我不是所謂軟工科系，是電子科喔。 ^^
倒是有個疑問，國內大專研究所有在教授所謂的 OOAD 嗎？
有些意見倒是與你不太一樣，重點不是 OOP, 也不是 OOAD，我會以為重點在於對軟體設計本質的探索與體悟。 🙂
標題不錯! 但是對於內容有意見!
你應該不是科班出生的!
重點是 OOAD !
Best Regards,
James
感謝您。
Hi Jason:
我這裡所有的文章均歡迎轉貼的，僅需註明出處即可。
物件導向基本觀念的書籍，國外很多，我想您可以在 Amazon 看看推薦就可以知道哪些書比較受歡迎了。
嗯，Odell 這本書是我的收藏品，精裝的外皮，質感可很好呢。 ^^
克明前輩：
小弟為急於進入物件導向分析設計新手，主管依其主觀要求先由OOP開始學習，還好拜讀了大作請允許小弟將本篇論述mail主管參考，另文中推薦閱讀James Martin/James J. Odell 合著 「Object-Oriented Methods」 一書似已絕版不知何處可購得。
感謝您!
感謝您，這兩天我會去找來看的。
Hi jaceju:
ASP 算是純 Web 的程式語言，若您想 “塑模” Web 端的應用系統，那麼這本： “Building Web Application with UML” 是很好的參考書籍。
該作者饒富創意，自行豐富了 Web 端的模型元素，因此而受到 Rational 的注意，而被延攬進入該公司。
「”暫時” 先把手頭工作的 ASP 放掉」
這句是良言，但是…客戶不準呀 ~~
我手邊還有 PHP 和 ASP.NET 的案子， ASP 只是一個其中某個案子的平台；而且重點是，要先把「錢」拿到手 (很現實的一件事) 。
不過我大略能瞭解您的用意，執著在語言上去實現物件導向思維並不是一件好事，若能拿掉眼前的這根管子，外面那片藍天也許會更廣闊。
接觸物件導向還不到一年的我，缺少的就是經驗和視野，能向您討教讓我覺得非常幸運；雖然不奢望從您那邊得到豐富的知識，但我想有時候一兩句話已足夠讓我深思。
無論如何，都感謝您。
Hi jaceju:
“暫時” 先把手頭工作的 ASP 放掉，如此比較能專心思考物件設計的思維。能從生活周遭的環境來觀察與思考，那會更為充實。 🙂
物件導向不僅如此
我在藍色小鋪發表我的 ASP 物件導向心得之後，在矇矇的秘密基地
嗯，其實我的想法也一直很模糊。
用 ASP 闡述是一種方式，但我只是想證明物件導向思維並不侷限在所謂正統的物件導向語言上，很多人都認為 ASP (VBScript) 及 PHP 只不過是 和 HTML 混雜在一起的 Script 語言，我想告訴他們那是長久以來的錯誤觀念。
其實我想要寫的是您說的「將 ASP 當作表達想法的工具」，只不過我的方向卻寫成「物件設計的想法，反而變成是配角」。我想我應該後面會再用實例來證明我的作法，因為那幾篇經您一提，反而變成是我在賣弄我所會的 ASP 皮毛。
感謝您的指點，我的看法獲得了一個新的角度。
PS. 這是我經您提點後的感想：http://blog.yam.com/jaceju/archives/1195928.html
Hi jaceju:
使用 ASP 來表達物件導向的設計思維當然不是旁門走道！ 我從來不會以為是這樣的。
我個人想建議您的是，我最後那一段話所提及的，你是將 ASP 當作表達想法的工具，還是 ASP 本身在你的心中是主角？
從你的文章論述，給我的感覺，比較偏後者，此時，物件設計的想法，反而變成是配角了。
感謝您的回覆 ^^
如我在文章一開始提到，有部份原因我們沒辦法使用較先進的技術，這也是我們的遺憾。
其實 ASP 確實有它先天上的限制，所以也不能完全說我用的就是物件導向，只不過我也沒什麼好名詞來表達它 (只因所學甚淺) 。
然而我想要的是它的容易擴充性和復用性，這點已經得到我們自己的證實，因為我的確在維護這個專案時，能夠適應客戶的需求修改；但要說服別人恐怕不是件易事，畢竟用 ASP 來表達物件導向在專家的眼中本來就顯得有點旁門左道 🙂
我還是會持續發掘 ASP 的可能性的，所謂道，本來就不是定型的，不是嗎？
再次感謝您的建言，我想我會換個角度來說明我心中的物件導向。
Hello jaceju:
拜讀了您的文章，可以感覺出，非常地用心。 🙂
以物件導向的思維在 ASP (VBScript) 開發專案，未嘗不可，我會比較懷疑一點，為何要堅持使用 ASP? 那並不是一個好工具。
不過，您的 ASP 文章仍是藉由程式語言的層級來解釋物件的思維。或許，轉個觀念，因為有物件導向的思維，並解釋為何你是這麼思考，然後，再利用 ASP 等語言的實做來輔助解釋你的想法與驗證，這樣比較能確認你想推銷的重點，是 ASP or 物件思維。
主從關係，確認後，您所寫的文章就能確定想表達的重心為何了。
Hi 賢智:
還真的是我認識的賢智。 ^^
我記得以前應該沒有向你解釋過關於物件導向的觀念吧？ 不過，以我當時的水平，也尚未初窺物件導向浩瀚無垠的世界。倒是，這幾年確實有持續走下來，嗯，Ringle 的體悟，又是比我更為深入透徹的呢。 🙂
站大您好：
我本身非常同意您這篇文章的論點，因為我試過以物件導向的思維在 ASP (VBScript) 開發專案，或許您會覺得不可思議，但以下是我的心得與成績：
http://www.blueshop.com.tw/article/show.asp?cde=ATL200512062211496AK
雖然如此，還有有網友質疑我的作法不是物件導向。因此我引用了您的論述來解釋，但我想或許我的說法還有不足。畢竟我實作過的專案並不多，在這些理論上的經驗太少，所能表達的意思或許不是最真確的。
如果您能對我的作法提出指正 (它是不是物件導向思維？) ，我想這對我的學習會是很大的幫助。
感謝您寫的這篇文章，它對我而言意義非常重大。
克明：
你現在說的OO和六年前的深度很不一樣。更實際了。
但就如你說的OO是一個思維，但是你將這個思維用太技術的方式呈現，就很容易讓別人用coding的邏輯去思考或理解。不過你現在的說明方式真的比以前要好很多。
不要從程式語言學習「物件導向」！
許多技術人員係從物件導向程式語言(OOP, Object-Oriented Programming Language)來學習物件導向，從 OOP 的角度來學習物件導向時，經常會把它當作是一種 “技術”，當作 “技術” 時，你會想去 “用” 它，而