許多技術人員係從物件導向程式語言(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"、頻寬的資料傳輸量的處理... 等。
所以，為什麼要使用物件導向？ 因為，物件導向是一種思維，是一種哲理，是一種典範，甚至是一種生活觀，你需要綜合相當多的知識，蘊化為 "智慧"，來協助你如何應付與應對軟體的 "善變"，並能提供具體的解決方案。嗯，這兩年突然對軟體設計某小一部分的哲理有一些 "頓悟" 後，每當看到許多系統因為粗製濫造而衍生出複雜的表象，眾多人們卻被淹沒在糾纏不清的問題與狀況時，而個人(外加 Ringle) 卻能 "一眼" 看出問題在哪裡，並且可以提出具體的解決方案，嘿，那可真是莫大的成就感與喜悅的呢。
學習物件導向的思維與哲理可是一條漫長之路。對我而言，我個人是已經選擇了這條 "自討苦吃" 之道，這條道路所要學習的廣度與深度，可是與圍棋之道一樣的深奧無比，每一個階段的學習與體悟，會讓你更接近與探索根本道理，但，似乎又永遠無法達到那個 "彼岸"。如同吳清源大師已經快 100 歲，仍舊每天研究圍棋；Ivar Jacobson 已經 80 餘歲，卻仍茲茲不倦地研究與發表軟體設計的論述一樣，這是終身職志，已經是融入每天的生活，永遠也研究不完的，甚至，還準備帶到下一輩子繼續來「修道」的。
所以，回頭來看物件導向程式語言，OOP 僅是實現(Implement)物件導向的工具，你會想透過 Java, VB.NET 等程式語言來實作如介面(Interface)、繼承(Inheritance)、多型(Polymorphishm) ...等設計。但問題是，OOP 無法告訴你 "What" and "Why" 介面、繼承、多型等這類屬於設計的哲理面(philosophy)，甚至，也無法告訴你 "What is Object?"、"How to divide the Object?" ...，而這些哲理，根本不是為了重覆使用或增進效能，目的旨於，協助人們在面對複雜的現象時，應用 "本來就有" 的智慧哲理，來解決複雜的問題，而 OOP，是讓軟體人員解決問題時，所需使用使用到的 "工具"，它就是工具，就是一種手段而已！
從 OOP 學習物件導向觀念是一種本末倒置的方向，那不會是一個好方法，若勉強說，利用 OOP 來 "驗證" 物件導向的一些設計想法，那到說得過去。那麼，從何處學習物件導向呢？ 我這兩年，是透過 "觀察" 生活的周遭環境，逐漸來反思與體悟的。這與我多年來閱讀許多大量其它領域的書籍，除了軟體設計專業書籍外，包括學習類、成功潛能類、企管與專案管理、歷史 ...等，實在有莫大的幫助，對短期的軟體技能幫助不多，但對中長期在軟體設計的思考上，會突然在某一個時間點突破而後 "頓悟"，這時再回頭看軟體專業各類的書籍，那可真是游刃有餘，輕鬆而能感受書中的作者所想表達的觀點與主題。
有感而發，既然，Java and .NET 都已經昭然若揭，程式語言確然往物件導向的實做之路，那麼，軟體人員也確實需要俱足物件導向的設計觀念。隨著工具的易學易用，以及網際網路龐大的資料庫，成為實做 "how-to" 的最佳參考來源，使得實做得以更形簡單。那麼，軟體人員更需要將精力擺在物件導向的設計思維，才有可能應對越形複雜的系統，懂得如何以簡御繁。
所以呢，我個人準備把我這幾年的一些心得與體會，盡量利用日常生活面的例子，來解釋物件導向的一些基本觀念與術語，例如，什麼是物件/類別、什麼是介面/多型、什麼是封裝 ...等。我會將這些文章另行分類成 "物件基本觀"。對了，有一些議題我會採反問的方式來闡述一些個人的物件觀。例如，若你要問我，EJB 是不是物件導向？ 我會說 "不是"；然而 Client/Server 是否是物件導向？，我的答案卻是 "Yes"。 呵呵，先賣個關子，這些是蠻有趣也蠻引起爭議的話題，爾後我會著文說明我的看法與理由的。