Shuffy

第23條：     盡量使用非成員非友元函數，而不是成員函數

請假想一個表示網頁瀏覽器的類。這個類可以提供諸多功能，其中包括清除下載緩存、清除訪問歷史、刪除系統中保存的 cookie 等等：

許多用戶可能需要同時執行這些操作，所以 WebBrowser 類應該提供一個函數來做這件事情：

當然，這一功能也可以通過一個非成員函數調用適當的成員函數來實現：

哪一個更好呢？是成員函數 clearEverything ，還是非成員函數 clearBrowser ？

面向對象的基本原理要求數據和對其進行操作的函數應該被包裝在一起，同時建議成員函數為更優秀的選擇。但不幸的是，這一建議并不是正確的。它是建立在對“面向對象的東西意味著什么”這一點的誤解之上的。通過理性分析可以得知，成員函數 clearEverything 的封裝性實際上比非成員函數 clearBrowser 還要差。還有，非成員函數可以為 WebBrowser 相關的功能提供更便利的打包方法，從而減少編譯時依賴，提高 WebBrowser 的可擴展性。很多情況下，非成員函數的方法都比成員函數的方法要好。理解這一結論的原因是十分重要的。

我們從封裝問題開始。如果一個物件被封裝了，那么它就是不可見的。它的封裝度越高，其它人或物件能看到它的機會就越少。能看到它的東西越少，我們對其進行修改的靈活性就越高，因為只有很少的物件能看到我們的改動。也就是說，一個物件的封裝度越高，系統賦予我們修改它的能力就越強。這就是我們為什么將封裝置于首要位置的原因：他為我們提供了改變物件的靈活性的方法，使用這一方法只會有很少的客戶端會受到影響。

請考慮與對象相關的數據。可以看到某一數據（也就是訪問這一數據）的代碼越少，就有更多的數據被封裝起來，從而我們修改這一對象的數據特征（比如數據成員的個數、類型等等）時就更為自由，粗略計算一下某一數據可以被多少代碼所訪問，我們就可以計算出有多少函數可以訪問這一數據：可以訪問它的函數越多，這一數據的封裝度就越低。

第 22 條中解釋了為什么要使用私有的數據成員，因為如果數據成員不是私有的，那么就有無窮的函數可以訪問它們。它們就毫無封裝性可言。對于聲明為私有的數據成員來說，可以訪問它們的函數的個數就等于成員函數的個數加上友元函數的個數，因為只有成員和友元可以訪問類中的私有數據。無論是成員函數（不僅僅可以訪問類中的私有數據，還可以訪問私有函數、 enum 類型、由 typedef 生成的類型符號，等等）還是非成員函數（上述成員函數可以訪問的所有內容都不可訪問）所提供的功能都是完全相同的，選擇非成員非友元函數可以帶來更完整的封裝度，因為它不會增加可以訪問類中私有部分的函數的數量。這就解釋了為什么使用 clearBrowser （非成員非友元函數）比 clearEverything （成員函數）更理想： clearBrowser 可以為 WebBrowser 提供更高的封裝度。

此刻我們需要關心兩件事情。第一，上面的推理過程僅僅適用于非成員非友元函數。由于友元對類中的私有成員的訪問權與成員函數相仿，因此是否使用二者都會對封裝度帶來一定的影響。以封裝的觀點，我們并不是在成員或非成員函數之間做出選擇，選擇的雙方應是成員函數和非成員非友元函數。（當然，封裝不是唯一的觀點。第 24 條中將為你介紹，當問題轉向“隱式類型轉換”時，選擇就在成員和非成員函數之間進行）

需要關注的第二件事僅僅是由于：封裝要求函數不應為類一個成員，而并不意味著要求它也不是其它類的成員。在某些語言中（比如 Eiffel 、 Java 、 C# 等等 ），所有函數必須包含在類中。對于習慣于使用這些語言的程序員來說，這第二件事多多少少可以算是對他們的一劑安撫藥。比如說，我們可以將 clearBrowser 定義為某個“實用工具類”中的靜態成員函數。只要它不是 WebBrowser 的一部分（或它的友元），它就不會影響到 WebBrowser 中私有成員的封裝性。

在 C++ 中可以使用一個更為自然的方法：將 clearBrowser 定義為一個非成員函數，并讓其與 WebBrowser 在同一個名字空間中：

然而，你得到的東西遠遠要比更自然的代碼要多。因為與類不一樣的是，名字空間可以延伸至多個源代碼文件中。這一點十分重要。 ClearBrowser 這樣的函數是 “便利函數”。由于它們既不是成員函數也不是友元，所以它在訪問 WebBrowser 時就沒有任何特權，從而它也就不能夠以其它的什么辦法提供 WebBrowser 的客戶端代碼所不具備的功能。舉例說，如果 clearBrowser 不存在的話，那么客戶端就只能自己動手調用 clearCache 、 clearHistory 和 removeCookies 這些函數了。

一個類似 WebBrowser 的類可能會有大量的便利函數，一些是關于書簽的，另一些是關于打印的，還有關于 cookie 管理的，等等。作為一個一般守則，大多數客戶端只會對這些便利函數中的一部分感興趣。舉例說，一個客戶端程序員可能只對與書簽相關的便利函數感興趣，但是書簽相關便利函數又依賴于 cookie 相關的便利函數，沒有理由讓這個程序員去關心那些額外信息。將著些便利函數分離開來的最直接的辦法就是：將書簽相關的便利函數聲明在一個頭文件中， cookie 相 關的為與另一個頭文件，打印相關的在第三個：

請注意：上面就是 C++ 標準庫的組織方式。標準庫使用了多個頭文件（包括 <vector> 、 <algorithm> 、 <memory> 等等），每一個都聲明了 std 名字空間中的某一些功能。而不是使用單態的 <C++StandardLibrary> 頭文件，并將 std 中所有的功能都羅列于此。對于僅希望使用 vector 相關功能的客戶端程序員，不應該強迫他們去 #include <memory> ；不希望使用 list 的客戶端也不需要去 #include <list> 。這樣就使得所有的客戶端程序員僅僅需要考慮他們正在使用的那部分系統中的編譯依賴問題。（參見第 31 條，其中介紹了解決減緩編譯依賴問題的其它途徑。）對于一個類的成員函數而言，以這種方式 分開管理功能是不可行的，因為一個類必須要保證其完整性，它不應該被分割成塊。

將所有的便利函數放置于多個頭文件中（但位于同一個名字空間中），同時也意味著客戶端程序員可以方便地擴展便利函數集。他們所需要做的僅僅是向同一名字空間中添加更多的非成員非友元函數。比如說，如果一個 WebBrowser 的客戶端程序員希望編寫一個關于下載圖片的便利函數，他或她僅僅需要 在 WebBrowserStuff 名字 空間中創建一個新的頭文件來聲明這些函數。新的函數與其它的便利函數一樣可用，一樣具有整合性。這是類無法提供的又一特性，因為類定義并不為客戶端程序員提供擴展性。當然，客戶端程序員可以派生新類，但是派生類仍無法訪問基類中的封裝（也就是私有）成員，所以我們說這樣的“擴展功能”只有“二等”身份。同時，如同第 7 條中所講，并不是所有的類都設計成了基類。

銘記在心

l 在特性情況下要更趨向于使用非成員非友元函數，而不是成員函數。這樣做可以增強封裝性，以及包裝的靈活性和功能擴展性。