物件導向技術的光環效應

要是你以為穿上一雙 Nike 球鞋，就可以像喬登一當抓球飛身灌籃，這叫做「錯覺」，是自欺欺人，不可能發生的事。

－－Phil Rosenzweig, 《光環效應》

近日聽到一些有關 OOAD 的正反意見，這篇文章只是在整理自己對這些意見的一點感想。

光環效應：過度渲染 OO

在碰到推廣 OO 技術的場合，常會聽到傳統的程序導向分析和物件導向分析的比較，並宣稱如果團隊採用 OOAD 方法，軟體專案將能夠獲得許多好處。以下是我最近聽到的一些說法：

• 更模組化。理由：藉由類別封裝，應用程式都會被切成適當大小的單元。（真的嗎？）
  
• 可提高重複使用性。理由：物件導向有繼承機制。（反面來看：牽一髮動全身的連鎖效應？）
• 應用程式更容易擴充。理由：未來如果需要增加一項新功能，我們只要增加一個類別，再動態「插入」既有的框架就行了，用戶端程式都不用修改。（如果設計得宜的話）
  
• 應用程式更好維護。理由：將來如果有一個地方要修改，我們就只要改 XX 類別就行了，其他地方都不用動。（如果設計得宜的話）
• 更自動化、更一致的開發模型。理由：我們使用自動化工具來設計和產生類別骨幹，程式設計師只要填肉進去就行了。（高度懷疑此說法，包括其實用性以及產出的品質；此外，我們是否正在將程式設計師塑造成不動腦筋的 coding machine？）
• 文件更清楚、更好管理。理由：我們全部使用 Use Case 規格來描述功能需求，所有的分析設計文件和模型都是用工具管理，所以文件更集中、好找，也更能清楚表達系統規格。（用工具集中管理的確有好處，但是跟文件內容是否清楚達意無關）

每當聽到有人宣稱只要採用 OO 就能獲得上述優點，我不禁懷疑，他曾經帶領或開發過幾個成功的 OO 專案？或者最起碼，寫過幾個 OO 程式？如果沒有用一個實際的小案例將整個設計 walk through 一遍，光憑這些接近廣告的說詞，實在很難確定他的團隊是否有把 OO 技術用在對的地方。

OO 技術可以協助設計師思考如何切割系統，將一個複雜的系統分出條理，切成幾塊，再針對各部分逐步細化、各個擊破。Grady Booch 等人在 《物件導向分析設計與應用》裡面指出：「對軟體的複雜性不夠了解，是導致專案延遲、預算超支、以及無法滿足需求的主要原因。」因此真正的關鍵在於如何對付軟體本身固有的複雜性，至於上面所說的那些 OO 優點，很多都是跟人如何用 OO 去設計，以及團隊的開發流程與專案管理實務有關。

淑女和賣花女的差別不在於她們的行為舉止，而是人們對待她們的方式。
－－蕭伯納《賣花女》

光環效應：聽說 OO 太理論

另一種極端，是對 OO 技術棄如敝屣，認為那根本是空談、是理想、空有理論的東西。就我個人的經驗，實際上抱持這些想法的人，或多或少都曾在 OO 的路上跌跤，或者受到過多反 OO 言論的感染，而沒有機會實作 OO、深入了解 OO 實際的優點（和缺點）。我想道理很簡單：如果未曾試著了解某件事物或某個人，又怎麼能對它妄加論斷呢？

我不是說每個不贊成 OO 技術的人都是如此，這只是陳述我自己碰過的情形。其實，就算在軟體專案中嘗試導入 OO 技術而不幸失敗，也不見得是 OO 本身的問題。專案失敗的因素通常很多，若沒有深入分析，就把失敗原因歸咎於採用 OO 技術，恐怕是太武斷了。

一位著名的統計學家指出，十九世紀的美國因為酒醉被捕的人數，和牧師的人數呈現明顯相關性。我們認為兩者人數的同時增加的確有明顯相關性，但卻沒有因果關係；此現象反而是另一個因素造成的：美國人口大幅增加。

－－ Stephen Jay Gould，《生命的壯闊》

以下是我所聽到的一些關於 OO 的批評與反面意見：

• OO 其實是很古老的技術了。
• OOP 還有些幫助，但 OOAD 的 reuse 根本是謊言，business objects 根本不能重複使用，每一個專案都要重寫。（儘管 business objects 很難跨專案 reuse，但分析設計的 patterns 還是可以重複使用。不要只看 code reuse，對設計師來說，design reuse 也很有幫助。記得要 reuse in the large）
  
• 其實台灣根本沒有多少人真正實行 OO 技術，甚至大學課程都沒什麼在教了，因為太理論了，上不了戰場。（呃...我沒有數據，但這說法似乎有打迷糊仗的嫌疑，以及因為自己不用或用得不好，所以也同理可證地認為別人沒在用或用得不好。）
• OO 方法設計出來的程式效能很差。（一般來說，如果類別階層較深，執行速度是會稍微慢一些，但如果「效能很差」指的是數倍以上的速度延遲，那可能得看程式或架構的設計，才能判斷是因為 OO，還是人的因素。）
  
• 現在的 OOAD 都被程式語言限制住了，大家都只會 Java、C++ 這些，所以思考方式都被程式語言的語法框住了，沒辦法想出更好的設計方法。（是程式語言本身的表達能力過於侷限而阻礙了人的思考，還是人的知識、技能、與想像力不夠？）
• 對一個問題的設計，John 可能會用 5 個類別來解決，Vivid 可能會有 3 個類別，而 Michael 可能就只用一個類別來解決。那麼，誰來決定哪一種設計是正確的？OO 的問題就在這裡，不像關聯式資料庫，還有正規化理論可以驗證；OO 設計根本沒有標準可言，那我們怎麼確定你的設計就是對的？（That's why we need architects and reviewers.）
  

人的思維的確會受限於既有工具的框架，但是專案的失敗或程式品質不良，真的絕大部分都是因為開發人員受到程式語言或工具本身的侷限而無法達到他所想要的設計嗎？這點我是挺懷疑的。

此外，最後一項批評認為：OO 設計沒有任何標準可茲驗證其正確性。這個說法我認為似是而非。我們不妨把「OO 設計」替換成其他字眼，應該就能看出它的問題在哪裡，例如：「結構化分析設計」、「敏捷開發方法」、「C++/Java/VB」。

好比蓋房子，工程師根據設計圖蓋了一棟大樓，是否有標準方法可以驗證這棟大樓的設計一定「正確」，因此住戶住起來都一定覺得舒服？如果有這種標準，我們買房子時就不用先看屋了，只要用工具檢測一下就知道這棟大樓設計的「正確性」。這跟防震、輻射檢測安全標準、或建築法規完全是兩回事；它牽涉的是設計的部分，比較偏向藝術，而非精確的科學。

軟體開發技術不斷改進，是為了提供更好的方法，以協助開發人員設計出品質更好的產品（當然不見得每個新方法都是好的）。我們可以試著遵循一些方法和最佳實務來改善設計的品質，但軟體該如何設計存乎一心，就像每個廚師都能用同一套工具和食材變出不同口味的菜色－－哪有要求驗證料理的口味是否符合「統一標準」的道理呢？

小結

這裡我就自己所見的情況整理了一些有關 OO 的正反兩面說法，並加入了個人的意見。我想，輕易全盤相信一套說詞總是不妥，我們能夠做的，還是多看、多學、多實作，並相信自己的體會吧。

最後謹以 Frederick Brooks 在《人月神話》中引用 David Parnas 的話作結尾：

「我們是否能寫出好程式或爛程式，跟使用什麼樣的工具並沒有關係。除非我們教大家如何設計，否則這些語言發揮的效用就會很有限，結果就是大家用了這些語言做出了爛設計。」