許多技術人員係從物件導向程式語言(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』。 呵呵，先賣個關子，這些是蠻有趣也蠻引起爭議的話題，爾後我會著文說明我的看法與理由的。