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

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

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

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

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

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

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