物件導向的分析方法發展至今也已經有十數個年頭了，現今也還是有許多公司使用非物件導向方式執行SA & SD的工作。也當然並不是說誰一定比較好，或是說一定非得使用物件導向的分析方式來設計系統，以前當OO的觀念並未盛行時大家不是也都可以將系統做得很好。那麼為什麼要使用物件導向的分析方法呢？
物件導向的分析方法發展至今也已經有十數個年頭了，現今也還是有許多公司使用非物件導向方式執行SA & SD的工作。也當然並不是說誰一定比較好，或是說一定非得使用物件導向的分析方式來設計系統，以前當OO的觀念並未盛行時大家不是也都可以將系統做得很好。那麼為什麼要使用物件導向的分析方法呢？我們先來看一下傳統的程序導向。
程序導向(Process Oriented)
所謂的程序導向隨即是將分析的焦點放在處理程序上，所有的資料均需要處理程序來處理，因此處理程序即來自使用者的需求。資料與處理程序是分開來思考的。什麼是資料什麼是處理程序呢，我們先定義一下：
資料：
如程式運作時所需之資料結構、區域變數、全域變數、動態資料、檔案…等。
處理程序：
程式運作或(執行)之程式碼或指令碼的片段。通常稱為函式(Function); 或同義詞中所表達的：程序(Procedure/ Sub-Routine)、功能(Action)等。
如上應該定義的非常清楚了，因此當程序邊更時通常配合的資料必須跟著修改，如下DFD的範例：
程序導向的基本思維認為，資料是資料，如果沒有處理程序來處理的話，資料還是只是存在的靜態資訊，是獨立存在的。可以透過下面(經典)的簡圖來表示：(圖覑取自Technologic Arts Inc., “UML參考辭典”)
所以一般程序導向的設計重心主要會在所需要的資料結構，例如：常應用在關聯式資料庫之實體關係模型(ER-Model)，同常就是一種圖形表示法 + 正規化(Normalization) 產出的資料模型。因為程序導向著重於處理程序，以輸入/輸出為主體的方式思考所處裡的資料。
物件導向(Object Oriented)
物件導向是一種思維，思考方式，物件導向將所有的事物都當成是『處理程序』與『資料』的綜合體，這是一種概念，物件導向認為資料與程式本身是密不可分，封裝，繼承等基礎概念可參考筆者以前的篇以Delphi為例解說物件導向程式語言的文章 [物件導向OOP基礎概論 (以Delphi為例)]。而在談論物件導向的思維前先來談談傳統的模組化，模組化有哪些好處呢？模組化可以
- 建立重複使用的處理程序
- 易於維護
- 減少錯誤發生，發生錯誤也易於Debug，也不至於引發更多錯誤。
- 容易擴充
等特性。但模組化還是無法解決對資料的相依性，可是何謂好的模組呢？這也是物件導向之所以會被發展出來的原因之一，通常一個好的模組應該具備如下兩個條件：
- 模組內 - 高內聚力(Cohesion)
- 模組間 - 低耦合度(Coupling)
因此在物件導向的『封裝』與『抽象化』等特性可以使應用程序與資料之間的相依性關係竟可能存在於物件 (類別) 的範圍之內。由於物件之間本身即有清楚的界線，因此非常例於產生低偶合度的模組，且抽象化也利於產生高內聚力的模組，即符合上述兩種特性。我想用不著多說明各位對於使用物件導向的好處已經非常清楚，我們來看底下這張比較『傳統程序導向開發』與『物件導向開發』的比較圖：
由此比較圖可以清楚的了解，使用物件導向分析的方式會使系統較容易維護，尤其在現今軟體系統日益龐大，加上使用者的需求又時常在改變，許多方法論的出現也是為了因應或說應付這樣的變化，使團隊合作有一個共通的方法，系統維護成本低，容易擴充。
一個簡單的比較，勘誤不吝指正，謝謝各位。
簽名：
學習是一趟奇妙的旅程
這當中，有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。
軟體開發之路（FB 社團）：https://www.facebook.com/groups/361804473860062/
Gelis 程式設計訓練營（粉絲團）：https://www.facebook.com/gelis.dev.learning/
如果文章對您有用，幫我點一下讚，或是點一下『我要推薦』，這會讓我更有動力的為各位讀者撰寫下一篇文章。
非常謝謝各位的支持與愛護，小弟在此位各位說聲謝謝!!! ^_^
