沒想到 PTT 的 Soft_Job 看版有人在聊 OOP 的觀念，忍不住作了一些回應。
- 早期把物件化的分析/設計思維歸為 OOA/OOD (Object-Oriented Analysis/Design)；實現物件化思維的程式語言則稱之為 OOP (OO Programming)。
- 實現 OO 思維主要有兩個機制：介面 (interface)、多型 (polymorphism)。包括 .NET/Java 等主流語言，早已支持 OOP，甚至連 php/python 等原來屬於 script-based 的程式語言，也朝向 OO 化的實現機制。
- 從 OOP 的角度來看到物件化的設計思維是不妥的；原因在於絕大數開發人員並不知道 Why OO Thinking！其實採用 OO 設計化思維是必然會增加開發成本的。因為它並非為了解決某一局部的邏輯性問題，而是考量全局，從系統整體來看待「變動 (Change)」的議題，進而提出如何擁抱改變 (embrace changing)的解決方案。
- 再則從實作上，OO 化的特徵是分散式的 (因為基於類別 (class)的責任分派 (responsibility assign)原則)。所以為了實現 OOP 的分散式架構，程式碼必然大量分散於各類別內，如此會造成實作與偵錯的難度；因而一個必要的配套措施：TDD (Test Driven Development)，測試先行是一定要養成的好習慣。
- 越是大型變動頻繁、高度維護，或者期待包裝為產品，增加其再利用性價值的系統，採以 OO 的設計/實現 (當然，前提要有這樣實在技能的軟體架構師/Developer)才能感受到其好處：每一次只改變一點點；每一次的變動可以侷限在可控制的變動範圍內。
- OO 的特徵是將 程序/資料 封裝至某一類別內，其實在抽象層次，程序稱之為「行為 (behavior)」、資料稱之為「屬性 (attribute)」，兩者均為物件必然會有的特徵 (features)，是非常自然不致分離的。但因現實仍沒有一種有效的機制能把物件的狀態 (state)儲存起來，所以實作技術上是把物件與資料分離，資料儲存於資料庫系統內、待執行期間 (run-time)才透過如 OR Mapping (如 .NET ER Framework、Java Hibernate 等)，將物件與資料合而為一。
- 實業界很有趣的一個現象：重視 MIS (Management Infomation System)系統的公司，幾採以資料導向的開發模式；重視 Web 框架如網路行銷公司，大都採以程序導向的開發模式。至於所謂的 OO 化，實現的程度其實還蠻微小的。
- 順待提下重構 (refactor)的觀念：重構是屬於事後 (Coding 後)的設計，一般與事前 (Coding 前，如典型的 SA/SD)設計可能存在著 3:7 或 4:6 (事前：事後)的比重。而且往往寫完程式才是另一段故事的開始：持續重構 (continous refactoring)。
- 重構的要件：不會影響到已經上線系統的所有功能。 衡量重構的指標：每一個 method 不會超過 10 行、最長不得超過 20 行。
- 如今重視 Web 相關技術、快速實現商業創意的年代，其實已少人有人談及 OO 更遑論具體實踐了。西元2000年以前，包括 UML 三大師 (Booch、Rumbaugh、Jacobson)、Martin Fowler (重構一書即為他的著作)、Kent Beck (XP/Agile 的始祖)、Bob (Clean Code 作者)均為支持物件思維的軟體大家。國外除了這些大師外，實現 OO 的專家其實也不多，一般是會落在如開發底層框架 (如 .NET Framework)的關鍵架構師。