iT邦幫忙

3

試比較結構化程式設計與物件導向設計──以成教通訊資料管理為例(及一個疑問)

試比較結構化程式設計與物件導向設計──以成教通訊資料管理為例

一般開發程式的作法, 是以使用者需求為導向, 寫程式的人則是把需要的資料正規化等過程.

例如成教的通訊資料, 就可能這樣分:
程式: (教務組)教師通訊資料管理, (學務組)學員通訊資料管理.
DB: 教師基本資料Table, 學員基本資料Table.
當中可能有部份程式碼是相同的功能, 例如: 查詢, 寫入, 則可以寫成 function 或副程式.

而物件導向的觀念, 則是把思考的角度轉換,
例如: 教師及學員都是成人, 成人都會有通訊資料, 教師則有相關學經歷, 學員則有選課記錄等.
把"成人"當成一個新物件, "修改成人通訊資料"成為一個方法(method).
則原本的程式就可能變成:
最上層: (課務組)教師通訊資料管理, 核對 user 權限.
第二層: 查詢符合教師身分的所有成人.
第三層: 處理成人工訊資料. (OO實作)
DB則會變成:
成人(聯結通訊資料)
教師(聯結學經歷, 開課記錄)
學員(聯結選課記錄)

單純以程式來看, 結構式的程式, 就有教師通訊資料管理, 指定寫到特定 Table , 如果要套用在學員資料管理, 則可能改一下 Table , 改成修改學員資料 Table , 但是如果有更多需要維護, 例如"員工通訊資料管理", 則又要再改寫一份, 將來如果資料結構有異動, 例如台北/台中電話改為 8 碼, 則需要同時異動多個 Table .

以 OO 的設計來看, "成人"跟"電話"就是不同的物件, 所以最外層雖然仍是"維護教師通訊資料", 但是中間把不同的功能, 例如呼叫已經 OO 化的"修改成人電話", 則屬於個人資料維護的程式, 就都可以共用.

不過這樣也就有個疑問了....如果規模很大, 有不同的個人資料要維護, 這樣共用程式當然可以減少程式總數, 遇到一次修改大量通訊資料(例如五都升格), 同一個資料庫也比較方便.
但如果有人 method 用 read , write ; 有人加了一個 search , 另外又有人加了一個 lookup , 則呼叫 OO 程式時, 就要先弄清楚該用 search 或 lookup , 而造成程式管理上的不便, 這樣是否也會是種負擔?


0
海綿寶寶
iT邦超人 1 級 ‧ 2013-10-07 23:47:04

我的疑問則是
以這樣單純的題目來分析
如果找三個人,用結構化程式設計的結果

找三個人,用OO設計的結果

那一類的差異會比較大
為什麼
疑惑

總裁 iT邦好手 1 級‧ 2013-10-08 08:33:04 檢舉

iT邦幫忙MVPantijava提到:
差異會比較大

這叫彈性....冷

slime iT邦大師 1 級‧ 2013-10-08 11:51:41 檢舉

可能效益要等更多相似的類型才有效率上的差異, 目前是看書覺得理論上不是很確定, 想問問看大家的經驗.

比如:
人 - 自然人跟法人
自然人 - 學生, 老師, 員工, 客戶, 廠商聯絡人, 捐款人, etc....
法人 - 廠商, 政府, etc....

這樣才有繼承的觀念吧.

slime提到:
人 - 自然人跟法人
自然人 - 學生, 老師, 員工, 客戶, 廠商聯絡人, 捐款人, etc....
法人 - 廠商, 政府, etc....

如果可以分成「自然人、法人」,那就也可以分成「男人、女人」
也許有人會認為「法人」並不是「人」(只是中文有同一個字,並無繼承其特性)

所以,我的疑問是
「同一套分析邏輯理論,為什麼由不同人來做,會做出差異如此大的結果」

結構化程式設計也是如此
但不同人的設計
彼此間差異不會差太多
暈

0
Albert
iT邦高手 1 級 ‧ 2013-10-08 00:38:26

vm,6vul4 University

vm,6vul4 University

還真是好英明
感謝 University
讓這些人永遠沒實作能力

0
fillano
iT邦超人 1 級 ‧ 2013-10-08 15:23:22

slime提到:
不過這樣也就有個疑問了....如果規模很大, 有不同的個人資料要維護, 這樣共用程式當然可以減少程式總數, 遇到一次修改大量通訊資料(例如五都升格), 同一個資料庫也比較方便.
但如果有人 method 用 read , write ; 有人加了一個 search , 另外又有人...(恕刪)

我的疑問在於,這個事情只有在OO會發生?另外,如果會發生,那要請問專案管理過程做了什麼?什麼沒做?

看更多先前的回應...收起先前的回應...

我也是這樣覺得

開發過程很多方法和設計都要經過報告,不是想加就加
即使加了,當有新人加入團隊時也要教育訓練
不是亂搞的

這個有個簡單的解釋
就是
不是發生在「建置階段」而是在「維護階段」

維護的人可能沒參與建置
為了快速修改
就這裡補補那裡貼貼

才能符合系統維護的原則之一
疊床架屋
暈

fillano iT邦超人 1 級‧ 2013-10-08 17:22:22 檢舉

這倒是...Orz

PHP的專案蠻有可能像這樣補成怪物...

slime iT邦大師 1 級‧ 2013-10-08 19:17:54 檢舉

謝謝大家的指教, 我會再看看其他實作例子再思考看看.

0
bizpro
iT邦大師 1 級 ‧ 2013-10-08 17:22:29

物件導向的核心價值是低耦合, 物件導向並未去掉結構化設計, 而是以"類別(class)和方法(method)"的觀念來看待問題(domain).

slime提到:
以 OO 的設計來看, "成人"跟"電話"就是不同的物件, 所以最外層雖然仍是"維護教師通訊資料", 但是中間把不同的功能, 例如呼叫已經 OO 化的"修改成人電話", 則屬於個人資料維護的程式, 就都可以共用.

以您的這一段"問題"來看, "修改成人電話"代表耦合度太高了, 電話本身的修改方法與是否是成人無關.

共用是一個必然的過程, 而不是目的, 低耦合才是. 如果不是低耦合, 就是假物件, 也是為成物件而物件.

0
bizpro
iT邦大師 1 級 ‧ 2013-10-08 17:32:53

slime提到:
但如果有人 method 用 read , write ; 有人加了一個 search , 另外又有人加了一個 lookup , 則呼叫 OO 程式時, 就要先弄清楚該用 search 或 lookup , 而造成程式管理上的不便, 這樣是否也會是種負擔?

這應該用介面(interface)繼承來做, 而不是修改原介面. 這樣也不會有任何混淆.

另外, 您是否把資料庫和物件混在一起了?

slime iT邦大師 1 級‧ 2013-10-08 19:11:00 檢舉

bizpro提到:
這應該用介面(interface)繼承來做, 而不是修改原介面. 這樣也不會有任何混淆.
另外, 您是否把資料庫和物件混在一起了?

可能是更低階的....完全還不懂.... ^^!

只是以前試著寫的一套成教選課, 在考慮改版, 所以找相關書籍來看, 而聯想到的案例, 由於尚未改寫, 所以先提出概念上的疑問.

bizpro iT邦大師 1 級‧ 2013-10-08 20:54:33 檢舉

slime提到:
可能是更低階的....完全還不懂.... ^^!

interface的觀念是基礎

我要留言

立即登入留言