物件導向程式設計與實作的基本理念
人多好辦事?
我們常常聽到大家說 "人多好辦事",
這是指在人手夠多的情況下,
透過適當的工作安排,
每個人可以分到適量、單一性質的工作,
他可以全神貫注來以最好最快的方法完成所分配到的工作。
如此整合起來十個人可以在一定時間內完成十份性質不同的工作,
但是如果同一個工作由一個人來做的話,
所需要的時間可能遠超過十倍的時間。
為什麼當一個人需要同時處理多項不同性質的工作時,
常常會容易出錯?
也常會使得處理工作的效率大幅降低呢?
相信大家都很能夠體會個中的原因,
因為多工的要求使得處理工作的複雜度提高了許多倍。
簡單地說,
在現實生活中要將工作完成得漂亮而且大家都能輕鬆愉快的不二法門就是 "分工",
而且要把各項工作之間的關係降到最低,
避免人與人之間的等待與溝通協調來浪費時間。
很典型而成功的範例如:
工廠中 "生產線" 的運作,
餐廳中經理、櫃台、廚師、跑堂之間的分工。
![](/images/greenline.gif)
程序式的分工
在設計 C/ BASIC/ PASCAL/ FORTRAN
這些類程式的時候最基本的分工概念就是函式,
每一個函式只處理一部分的資料,
做單一性質的工作,
大家一定知道函式不要用全域的變數,
所以函式和外界的溝通主要靠參數,
看起來非常理想,
假設每一個函式代表一個人,
人和人之間的溝通就只需要像生產線上一樣,
把完成的半成品送上輸送帶就可以了。
對於任何一個問題,
如果你能夠定義出原料、半成品、成品這樣子制式的流程的話,
你就可以輕鬆地完成分工。
可是真的所有的問題都可以用資料流或是控制流來分析、定義嗎?
試想一個小畫家程式,
你能夠要求使用者在畫面左方先畫一個圓,
擦掉一半,
剪下 1/4,
移到右下方... 嗎?
如果動作的組合很多很多種的話,
就可能畫不出控制流或是資料流了,
至少相當地不容易,
如果你真的把控制流程畫出來了的話,
你也很可能會發現你的程式彈性很小,
使用者不太能夠做什麼更動,
只能配合著你事先分析出來的控制流程來操作,
因此扮演著分配工作的程式設計師遇到這種狀況會是非常頭痛的,
有些工作的分配不是應該留給使用者自己去做嗎?
![](/images/greenline.gif)
物件的分工與封裝
物件導向程式設計的基本理念可以由上面餐廳中分工的例子中了解,
首先運用不同物件的組合來構成分工的基礎,
各個物件掌管性質不同的功能與工作,
程式設計者必須扮演分配工作的角色,
只要工作分派得宜,
每一個物件的各種行為應該都是很直觀、很單純、輕鬆愉快的,
對於假想的擬人化物件而言,
輕鬆愉快也就是代表實際上程式設計者在實作程式細節時的輕鬆愉快。
以小畫家的例子來說,
程式中要有一個物件負責了解使用者的動作與需求,
要有一個物件專門負責畫面中所有的內容資料,
要有一個物件負責畫圖工具箱的管理,
要有一個物件負責讓使用者設定工具的顏色,
也許再設計一個物件負責各種圖片檔案的轉換...
使用一個新的物件的原則就像前面一段所說的,
每一個物件不要負責太多種類的工作。
如果工作分配完了以後發現有某一個人的工作特別難完成,
這通常就代表人手不夠或是工作分派不當,
前者的解決方法就是新增適當功能的物件來協助,
再進一步進行工作內容的調整;
後者最常看到的現象是完成某一工作需要許多人提供資料與協助,
解決的方法就是叫那些提供資料的人多做一些處理,
減少資料的傳遞,
或是叫那些提供技術的人多管理一些資料,
減少合作群體中人員的同步。
"封裝" 就是 "把資料隱藏起來",
這是非常直覺的說法,
可是這樣子的說法太偏向定性的定義,
反而有一點盲目,
並沒有說中物件導向設計時的關鍵,
好端端的資料難道這麼見不得人嗎?
為什麼要藏起來?
這個嘛!
應該說是免得礙眼,
怕太亮眼干擾到別人的工作,
怕引誘別人直接運用這些資料去進行他們自己的工作,
如果我們由物件導向設計的基本理念來看封裝的概念的話,
封裝可以說是 "只提供服務",
是一種分工概念的完成手法。
程式中的物件們提供各種服務,
使用者基本上也是物件,
使用者和程式中的物件們一起工作,
共同來完成目標。
在這樣的架構下我們把許多操作物件的彈性留給使用者,
讓他自己選擇。
![](/images/greenline.gif)
比較難還是比較簡單呢?
物件導向程式的設計與實作比起程序導向式的設計與實作到底是比較難還是比較簡單呢?
大家常說物件導向式的軟體程式碼比較大,
比較好維護與擴充,
所以是不是就應該比較難設計了呢?
常常有人報怨說在開始設計時不曉得該有哪些物件,
物件內該存放哪些資料,
物件該提供哪些服務?
怎樣設計才會最好?
感覺上需要很多經驗才能一次就做得好,
不過不要太擔心,
實際社會中也是很少有一開始分工就完全正確的,
常常也是一步一步地視工作進行狀況來修正,
分工不適當的物件會自己顯現出來的,
就好像團體合作時特別累的成員會不斷地抱怨一樣。
此外適當封裝的程式是很容易重組的,
不管是資料由一個物件移動到另外一個物件,
或是服務由一個物件提供換成由另外一個物件來提供都是一樣,
所以其實一開始的物件設計其實是不需要過度憂心的,
可以盡量依照自己統合一件工作時的直覺來設計,
反正還可以再更改,
比起程序式設計的程式來說,
設計錯誤所要付出的代價其實是比較小的。
![](/images/rainbow.gif)