物件導向技術的光環效應
Michael Tsai
11/24/2008
要是你以為穿上一雙 Nike 球鞋，就可以像喬登一當抓球飛身灌籃，這叫做「錯覺」，是自欺欺人，不可能發生的事。
－－Phil Rosenzweig, 《光環效應》
近日聽到一些有關 OOAD 的正反意見，這篇文章只是在整理自己對這些意見的一點感想。
光環效應：過度渲染 OO
在碰到推廣 OO 技術的場合，常會聽到傳統的程序導向分析和物件導向分析的比較，並宣稱如果團隊採用 OOAD 方法，軟體專案將能夠獲得許多好處。以下是我最近聽到的一些說法：
- 更模組化。理由：藉由類別封裝，應用程式都會被切成適當大小的單元。（真的嗎？）
- 可提高重複使用性。理由：物件導向有繼承機制。（反面來看：牽一髮動全身的連鎖效應？）
- 應用程式更容易擴充。理由：未來如果需要增加一項新功能，我們只要增加一個類別，再動態「插入」既有的框架就行了，用戶端程式都不用修改。（如果設計得宜的話）
- 應用程式更好維護。理由：將來如果有一個地方要修改，我們就只要改 XX 類別就行了，其他地方都不用動。（如果設計得宜的話）
- 更自動化、更一致的開發模型。理由：我們使用自動化工具來設計和產生類別骨幹，程式設計師只要填肉進去就行了。（高度懷疑此說法，包括其實用性以及產出的品質；此外，我們是否正在將程式設計師塑造成不動腦筋的 coding machine？）
- 文件更清楚、更好管理。理由：我們全部使用 Use Case 規格來描述功能需求，所有的分析設計文件和模型都是用工具管理，所以文件更集中、好找，也更能清楚表達系統規格。（用工具集中管理的確有好處，但是跟文件內容是否清楚達意無關）
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 的話作結尾：
「我們是否能寫出好程式或爛程式，跟使用什麼樣的工具並沒有關係。除非我們教大家如何設計，否則這些語言發揮的效用就會很有限，結果就是大家用了這些語言做出了爛設計。」
