目前工作上所接觸的程式 還是以資料導向的思維來建構的，這類的程式，需要調整的時候，不但規劃與開發的速度慢，而且容易錯誤百出，真是苦不堪言。
後來有的程式漸漸以物件導向的思維來設計與建置，狀況就好多了，可以處理更複雜的邏輯，開發的速度也必較快。回過頭去，實在很難想像，如果要以資料導向的思維來設計與建構 複雜的系統(例如 Excel)，會是多麼吃力的事情。
軟體系統會出錯，也就是軟體本身所隱含的風險，如果物件導向的思維與設計模式，可以有效地降低軟體系統的風險，那麼，這種思維與設計模式，是否也可以用於 一般性的專案管理工作上呢?
軟體系統內部，是由單位(物件)、事件、訊息、與行為 組成的，一般性的專案其實也是，例如: 建造一棟房子的過程，也是由很多個體、事件、訊息、與行為所組成的。
我在想: 是否也可以將物件導向的思維與設計樣式，運用在一般性專案的規劃與管理上? 能有效降低專案的風險，提升專案的達成率與效能嗎?
話說: 物件導向的設計模式，真的能有效降低軟體的風險嗎? 封裝、多型、繼承、高內聚、低耦合，到底是哪一部分最能降低風險呢?
