對於任何早期撰寫過DOS或VB6的開發者而言，流程導向和結構導向的開發觀念，是再自然不過的行為（即使物件導向的發明已多年）。那為何近幾年來，微軟的VB.Net、Action Script3等知名軟體語言，近年紛紛向物件導向靠攏？我想應該是人類對於系統的要求，不論深度、廣度都遠比早期大上好幾倍外，人們更希望有效縮短開發時程，並隨時因應修改和擴展。這種又要馬兒好，又要馬兒不吃草的環境下，有時人們根本連他們需要哪種品種的馬都不清楚的情況下，就要求系統開發團隊生一隻出來，這樣不但會生出四不像之外，可能連繁殖力（擴展）都有問題，於是常態性的加班與熬夜，就這樣成了我們開發人員的標籤。
因此，如何開發出容易維護、容易擴展、容易覆用的系統，是開發人員致力的目標，而當我和您越深入了解物件導向，就越能夠感受物件導向的優點和存在價值，它似乎就是專門解決這些問題的天生好手。
然而物件導向固然有能力解決上述問題，但有太多開發者依然無法享受到物件導向的強大優勢和樂趣。以微軟VS.NET來說，許多開發者常誤以為自己在這套IDE開發工具下所開發出來的系統，就表示自己已經擁有物件導向開發的能力，但實情並非如此！因多數人（特別是初學者）只是藉著開發環境來撰寫架構導向的程序罷了（猶如在OFFICE WORD中，只單純打字就宣稱自己會使用WORD）。
以程式撰寫初期來說，物件導向式的開發所花費的時間成本，可能會是架構導向方式的好幾倍，這當中的系統分析師和系統設計師的能力，我個人認為是影響最劇者。而需求單位、系統分析師、系統設計師、程式設計師四者間，可利用ＵＭＬ來當成討論系統的共通語言（如：使用者案例圖、類別圖、循序圖等），一旦統一了討論語言，有助於提高溝通上的理解之精確度。
即便當我們了解物件導向的語法和種種特性，但仍無法享受它的益處，這該怎麼辦？我個人認為最快的方式，應是學設計模式吧！當我們透過設計模式的洗禮，只會讓我們更謙虛，更佩服這些模式是如此的有用和有趣，非常感謝這些高手願意整理並且分享他們長年開發所遇到的問題解決方式，好讓我們透過這些經驗來內化成自己的系統所需。
