Visual Studio 2010_塑模化應用程式設計(五)[傳統程序導向 vs 物件導向]

  • 8156
  • 0
  • UML
  • 2012-04-02

物件導向的分析方法發展至今也已經有十數個年頭了,現今也還是有許多公司使用非物件導向方式執行SA & SD的工作。也當然並不是說誰一定比較好,或是說一定非得使用物件導向的分析方式來設計系統,以前當OO的觀念並未盛行時大家不是也都可以將系統做得很好。那麼為什麼要使用物件導向的分析方法呢?

物件導向的分析方法發展至今也已經有十數個年頭了,現今也還是有許多公司使用非物件導向方式執行SA & SD的工作。也當然並不是說誰一定比較好,或是說一定非得使用物件導向的分析方式來設計系統,以前當OO的觀念並未盛行時大家不是也都可以將系統做得很好。那麼為什麼要使用物件導向的分析方法呢?我們先來看一下傳統的程序導向。

程序導向(Process Oriented)

所謂的程序導向隨即是將分析的焦點放在處理程序上,所有的資料均需要處理程序來處理,因此處理程序即來自使用者的需求。資料與處理程序是分開來思考的。什麼是資料什麼是處理程序呢,我們先定義一下:

資料:

如程式運作時所需之資料結構、區域變數、全域變數、動態資料、檔案…等。

處理程序:

程式運作或(執行)之程式碼或指令碼的片段。通常稱為函式(Function); 或同義詞中所表達的:程序(Procedure/ Sub-Routine)、功能(Action)等。

如上應該定義的非常清楚了,因此當程序邊更時通常配合的資料必須跟著修改,如下DFD的範例:

image

程序導向的基本思維認為,資料是資料,如果沒有處理程序來處理的話,資料還是只是存在的靜態資訊,是獨立存在的。可以透過下面(經典)的簡圖來表示:(圖覑取自Technologic Arts Inc., “UML參考辭典”)

image

 

所以一般程序導向的設計重心主要會在所需要的資料結構,例如:常應用在關聯式資料庫之實體關係模型(ER-Model),同常就是一種圖形表示法 + 正規化(Normalization) 產出的資料模型。因為程序導向著重於處理程序,以輸入/輸出為主體的方式思考所處裡的資料。

物件導向(Object Oriented)

物件導向是一種思維,思考方式,物件導向將所有的事物都當成是『處理程序』與『資料』的綜合體,這是一種概念,物件導向認為資料與程式本身是密不可分,封裝,繼承等基礎概念可參考筆者以前的篇以Delphi為例解說物件導向程式語言的文章 [物件導向OOP基礎概論 (以Delphi為例)]。而在談論物件導向的思維前先來談談傳統的模組化,模組化有哪些好處呢?模組化可以

  1. 建立重複使用的處理程序
  2. 易於維護
  3. 減少錯誤發生,發生錯誤也易於Debug,也不至於引發更多錯誤。
  4. 容易擴充

等特性。但模組化還是無法解決對資料的相依性,可是何謂好的模組呢?這也是物件導向之所以會被發展出來的原因之一,通常一個好的模組應該具備如下兩個條件:

  • 模組內 - 高內聚力(Cohesion)
  • 模組間 - 低耦合度(Coupling)

因此在物件導向的『封裝』與『抽象化』等特性可以使應用程序與資料之間的相依性關係竟可能存在於物件 (類別) 的範圍之內。由於物件之間本身即有清楚的界線,因此非常例於產生低偶合度的模組,且抽象化也利於產生高內聚力的模組,即符合上述兩種特性。我想用不著多說明各位對於使用物件導向的好處已經非常清楚,我們來看底下這張比較『傳統程序導向開發』與『物件導向開發』的比較圖:

image

由此比較圖可以清楚的了解,使用物件導向分析的方式會使系統較容易維護,尤其在現今軟體系統日益龐大,加上使用者的需求又時常在改變,許多方法論的出現也是為了因應或說應付這樣的變化,使團隊合作有一個共通的方法,系統維護成本低,容易擴充。

一個簡單的比較,勘誤不吝指正,謝謝各位。


 

簽名:

學習是一趟奇妙的旅程

這當中,有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。

軟體開發之路(FB 社團)https://www.facebook.com/groups/361804473860062/

Gelis 程式設計訓練營(粉絲團)https://www.facebook.com/gelis.dev.learning/


 

如果文章對您有用,幫我點一下讚,或是點一下『我要推薦,這會讓我更有動力的為各位讀者撰寫下一篇文章。

非常謝謝各位的支持與愛護,小弟在此位各位說聲謝謝!!! ^_^