老師問到：「為何要用 OO 」？
有同學回答：「Reuse」。
六年前的我，也是這個答案。一個對於 OO 參透不深的人，通常的答案都是 Reuse 。
記得 2003 年，我初出茅廬，到一家叫做「物件動力」的公司面試，為了面試，當然要惡補一下物件導向，所以稍微瞭解了一下 PIE (Polymorphism, Inheritance, Encapsulation) ，查了一下物件導向的好處，就去面試了，考官當然會問這個問題囉，我的回答也是 Reuse 。
六年後，經過六年的實際體會，我的心得是：「 Deal with changes 」！ Reuse 只是 Deal with Changes 時所產生的一個好的副作用，就像有人吃痘痘藥，結果胸部變大一樣。
記得有一年，因教育訓練的關係，我認識一位台灣軟工界傑出的女性：邱郁惠小姐（她的 blog 如下： http://www.umltw.com/ ），她是我們公司聘請過來做 OO 教育訓練的講師，他對「 Why Object-Oriented? 」的看法是：
Process-Oriented 的基礎是流程，Object-Oriented 的基礎是物件，在真實世界中，物件相對比流程來的穩定，因此我們會希望我們的系統能夠 Base on 一個相對穩定的基礎來開發，因此我們選擇物件導向。
我覺得她說得算有道理，至今我還一直相信她的想法，舉例來說：
一個旅館系統來說好了，今天我們要提供一個房客可以自行上網預訂房間的流程，過了一個月以後，我們可能又要提供一個客戶滿意度調查的流程，再過一個月，我們可能又要加一個客戶列入黑名單的流程，半年後，我們發現預定房間的流程有瑕疵，應該在訂房前要先檢查房間數夠不夠，所以又加了一個可用房間檢查流程。
隨著使用者需求的改變，我們的流程也不斷的變更。
做軟體最常用的一招叫做 Divide and Conquer ，把一個大的東西，切割成小的單元 - Software Element ，然後把小的單元一一征服後，軟體就完成了。
如果今天我們切割 Software Element 的方式是 Base on 流程來切割，會發生什麼現象。
1.預訂房間： 1 個 Software Element 。
2.加客戶滿意度調查： 2 個 Software Element
3.加客戶列入黑名單：3 個 Software Element
4.加可用房間檢查：房間預訂流程再切割成兩個子流程。
隨著流程的改變，我們的 Software Element 的切割也跟著改變，系統架構很不穩固。
如果我們 Base on 物件來做切割，而非流程，會呈現什麼情況？
1.預訂房間： 3 個 Software Element 。
2.加客戶滿意度調查： 3 個 Software Element
3.加客戶列入黑名單：3 個 Software Element
4.加可用房間檢查：3 個 Software Element
到目前為止，不管流程怎麼改，系統的架構上都是 3 個 Software Element 。
以穩定的架構來應付多變的流程，我想應該是使用 Object-Oriented 的一個很好的理由之一。而穩定的東西，才能達到比較容易達到 Reuse 。如果今天某個 Software Element 一天到晚改變，你敢 Reuse 它嗎？ Reuse 它以後他改變了可是會影響到你喔！
這也是為什麼我認為 Reuse 只是 Deal with Changes 的一個好的副作用的原因。當然物件導向的系統架構也只是比流程導向相對穩定而已，要做得更好，還必須使用很多物件導向延伸出來的方法才行，比如： Design Pattern 。
除了 Deal with Change 外，還有一些理由我覺得不是很充分的有：
- 更貼近真實世界的運作方式
- 更符合人類思考的方式
這些都是坊間的一些書會提到的，我想這些書都抄來抄去，所以理由也都差不多。但我一直覺得這些理由並不充分。
「更貼近真實世界的運作方式」
那又如何？能帶給我什麼好處嗎？為何我的系統要更貼近真實世界？
而且事實並非如此，就拿旅館預定系統的例子來說好了，如果你要檢查目前房間有沒有空著，在真實世界上誰會負責去做這件事？應該是旅館服務人員，或顧客自己去看，但我們的設計卻是房間自己檢查自己有沒有空著。並不跟真實世界相符阿！
有人會說：貼近真實世界會讓你的系統看起來更直覺，更容易理解，但每個人看世界的方式與角度都不同，我對這個世界的理解跟你對這個世界的理解可能差異很大，因此你用你對這個世界的理解方式寫出來的系統，對我來說可能並不直覺，也不合理。
「更符合人類思考的方式」
有人說（甚至 N 年前我也曾經這樣說過），程式語言進化到 OO 是因為 OO 更貼近人類思考的方式，因為電腦是以程序的方式運作，所以我們早期的程式語言都是為了遷就電腦，所以也用程序的方式來撰寫程式語言，慢慢的為了讓語言更貼近人類思考的方式，所以演化出物件導向語言來。
如果真的是這樣的話，那原本學程序導向語言的人類，接觸 OOP ，應該會如魚得水吧！但真相卻是一些寫 COBAL 的老人要叫他寫 Java 簡直要他的命。
他們的思考方式是這樣：
電腦 = 計算機
計算機 is
[我輸入一些東西]
[經過他的一番運算]
[他會給我一個值]
然後我再輸入一些東西，他會再給我一個值，然後經過一番連續的 input-process-output ，最後得到我想要的一個結果。
這樣的思考方式也沒錯阿，他把電腦軟體當作一個冰冷的工具，他永遠沒法想像軟體，就像一個真實世界的縮影，裡面有個虛擬的客戶，虛擬的房間，此虛擬的客戶會對虛擬的房間做出預訂的動作，然後我們在這個虛擬世界外面的人，透過螢幕看到這虛擬世界所運作的結果。
因此我覺得「更符合人類思考的方式」，只是更符合發明物件導向的人所思考的方式而已，並非全人類。每個人對要完成一件事情的思考方式都不一樣，並非每個人都會幻想出一個虛擬世界來完成他的任務。
到目前為止我的參透，物件導向帶給軟體界的好處只有 Deal with Changes 而已，而且也並非能完全解決 Changes 的問題。
沒有留言:
張貼留言