臃腫的C++ – 淺談過度封裝

標題: 臃腫的C++ - 淺談過度封裝

作者: 闕榮文(querw@sina.com)

日期: 2010-12-3

摘要: 淺談由於對C++物件模型的濫用導致C++程式臃腫不堪的狀況.

幾乎所有使用OO語言(C++, Java)的程式員都有過度封裝的傾向.
不管什麼都先用類包一層.代碼的層次非常厚.很多C++原始碼由於封裝層次過多,有時候甚至為了封裝而封裝,讀起來非常費勁. 因為很多東西都是經過原作者抽象過的,如果讀者對作者的設計思想把握得不好,讀起來有雲裡霧裡的感覺.

我傾向於C++應該僅僅只是"帶類的C", STL應該維持在一個最小的集合內
.

C語言是最接近程式設計本質的語言,自由,靈活, 純言語言的東西很少. C的確是一個很小,很簡潔的語言.
看高品質的C程式是一種享受,行雲流水,是人類思維理解電腦世界的最直接的表述.
C的指標和數組是電腦世界裡最直接的體現. 在記憶體裡,資料就是這樣儲存的.CPU就是用指標(地址)來操作的.
相反,C++ 的 string 會讓你和實際記憶體聯絡起來嗎?

BOOST是一個非常大的庫,功能非常豐富,很多BOOST庫的確非常好,但是隱藏了太多細節.
人們常說BOOST是"准"標準庫, 我倒是希望它永遠都不成為標準庫,只是一個功能豐富的庫,需要的人用它,僅僅如此而已.

拿 share_ptr 作個例子,封裝得非常全面,依靠 share_ptr 幾乎可以忘記 new 和 delete. 依賴於 share_ptr 將不知資源的申請和釋放為何物.然而,這正是理解電腦世界非常重要所必需的. 從作業系統的角度來看,所有資源都是需要申請,也是必須收回的.
C++的過度封裝,使我們漸漸遠離程式的本質
.

對於STL的 auto_ptr 我認為剛剛好,提供了幾乎是最小功能要求的智能指標類型,一點多餘的東西都沒有,完全不會影響程式員對於指標,資源概念的理解.
用 auto_ptr 的時候,我心裡很清楚, 我只是讓 auto_ptr 在一個合適的時間合適的地點幫我把申請到的資源釋放.
使用 share_ptr 完全代替 new, delete, 我認為是非常愚蠢的嘗試,等同於嘗試在C++裡加入記憶體回收機制.
在C++這樣自由的語言裡,管理記憶體是一件非常愉悅的事. 記憶體流失? 那是程式員的問題吧.

為什麼很多C程式員堅持只用C? 我敢說C++的過度封裝是一個原因.
代碼層次越多程式越複雜,也就越容易出錯.
C程式員對電腦的理解絕對比C++/JAVA程式員對電腦理解來得深刻.

Linus Torvalds前不久針對為Linux核心開發而專門打造的版本控制軟體Git時說:
"C++是一種糟糕的（horrible）語言. 而且因為有大量不夠標準的程式員在使用而使情況更糟,以至於極容易產生徹頭徹尾的垃圾(total and utter crap)"
"低效的抽象編程模型,可能在兩年之後你會注意到有些抽象效果不怎麼樣,但是所有代碼已經依賴於圍繞它設計的‘漂亮’物件模型了,如果不重寫應用程式,就無法改正."
"也就是說,使用優秀的,高效的,系統級的和可移植的C++的唯一方式,最終還是限於使用C本身具有的所有特性.專案限制式只用C,意味著參與的人不會搗亂,也意味著會得到許多真正懂得底層問題,而不會折騰那些白癡‘物件模型’垃圾的程式員."

雖然我也是一個C++程式員,但是不得不承認Linus Torvalds說的是對的.
對物件模型的濫用和過度封裝正把C++引入絕路. 然而,這能說這是C++的錯嗎?