【轉(zhuǎn)】http://m.shnenglu.com/tiandejian/archive/2007/06/11/ec_23.html
第23條： 盡量使用非成員非友元函數(shù)，而不是成員函數(shù)
請假想一個(gè)表示網(wǎng)頁瀏覽器的類。這個(gè)類可以提供諸多功能，其中包括清除下載緩存、清除訪問歷史、刪除系統(tǒng)中保存的 cookie 等等：
class WebBrowser {
public:
...
void clearCache();
void clearHistory();
void removeCookies();
...
};
許多用戶可能需要同時(shí)執(zhí)行這些操作，所以 WebBrowser 類應(yīng)該提供一個(gè)函數(shù)來做這件事情：
class WebBrowser {
public:
...
void clearEverything(); // 調(diào)用 clearCache 、 clearHistory
// 以及 removeCookies
...
};
當(dāng)然，這一功能也可以通過一個(gè)非成員函數(shù)調(diào)用適當(dāng)?shù)某蓡T函數(shù)來實(shí)現(xiàn)：
void clearBrowser(WebBrowser& wb)
{
wb.clearCache();
wb.clearHistory();
wb.removeCookies();
}
哪一個(gè)更好呢？是成員函數(shù) clearEverything ，還是非成員函數(shù) clearBrowser ？
面向?qū)ο蟮幕驹硪髷?shù)據(jù)和對其進(jìn)行操作的函數(shù)應(yīng)該被包裝在一起，同時(shí)建議成員函數(shù)為更優(yōu)秀的選擇。但不幸的是，這一建議并不是正確的。它是建立在對“面向?qū)ο蟮臇|西意味著什么”這一點(diǎn)的誤解之上的。通過理性分析可以得知，成員函數(shù) clearEverything 的封裝性實(shí)際上比非成員函數(shù) clearBrowser 還要差。還有，非成員函數(shù)可以為 WebBrowser 相關(guān)的功能提供更便利的打包方法，從而減少編譯時(shí)依賴，提高 WebBrowser 的可擴(kuò)展性。很多情況下，非成員函數(shù)的方法都比成員函數(shù)的方法要好。理解這一結(jié)論的原因是十分重要的。
我們從封裝問題開始。如果一個(gè)物件被封裝了，那么它就是不可見的。它的封裝度越高，其它人或物件能看到它的機(jī)會就越少。能看到它的東西越少，我們對其進(jìn)行修改的靈活性就越高，因?yàn)橹挥泻苌俚奈锛芸吹轿覀兊母膭印Ｒ簿褪钦f，一個(gè)物件的封裝度越高，系統(tǒng)賦予我們修改它的能力就越強(qiáng)。這就是我們?yōu)槭裁磳⒎庋b置于首要位置的原因：他為我們提供了改變物件的靈活性的方法，使用這一方法只會有很少的客戶端會受到影響。
請考慮與對象相關(guān)的數(shù)據(jù)。可以看到某一數(shù)據(jù)（也就是訪問這一數(shù)據(jù)）的代碼越少，就有更多的數(shù)據(jù)被封裝起來，從而我們修改這一對象的數(shù)據(jù)特征（比如數(shù)據(jù)成員的個(gè)數(shù)、類型等等）時(shí)就更為自由，粗略計(jì)算一下某一數(shù)據(jù)可以被多少代碼所訪問，我們就可以計(jì)算出有多少函數(shù)可以訪問這一數(shù)據(jù)：可以訪問它的函數(shù)越多，這一數(shù)據(jù)的封裝度就越低。
第 22 條中解釋了為什么要使用私有的數(shù)據(jù)成員，因?yàn)槿绻麛?shù)據(jù)成員不是私有的，那么就有無窮的函數(shù)可以訪問它們。它們就毫無封裝性可言。對于聲明為私有的數(shù)據(jù)成員來說，可以訪問它們的函數(shù)的個(gè)數(shù)就等于成員函數(shù)的個(gè)數(shù)加上友元函數(shù)的個(gè)數(shù)，因?yàn)橹挥谐蓡T和友元可以訪問類中的私有數(shù)據(jù)。無論是成員函數(shù)（不僅僅可以訪問類中的私有數(shù)據(jù)，還可以訪問私有函數(shù)、 enum 類型、由 typedef 生成的類型符號，等等）還是非成員函數(shù)（上述成員函數(shù)可以訪問的所有內(nèi)容都不可訪問）所提供的功能都是完全相同的，選擇非成員非友元函數(shù)可以帶來更完整的封裝度，因?yàn)樗粫黾涌梢栽L問類中私有部分的函數(shù)的數(shù)量。這就解釋了為什么使用 clearBrowser （非成員非友元函數(shù)）比 clearEverything （成員函數(shù)）更理想： clearBrowser 可以為 WebBrowser 提供更高的封裝度。
此刻我們需要關(guān)心兩件事情。第一，上面的推理過程僅僅適用于非成員非友元函數(shù)。由于友元對類中的私有成員的訪問權(quán)與成員函數(shù)相仿，因此是否使用二者都會對封裝度帶來一定的影響。以封裝的觀點(diǎn)，我們并不是在成員或非成員函數(shù)之間做出選擇，選擇的雙方應(yīng)是成員函數(shù)和非成員非友元函數(shù)。（當(dāng)然，封裝不是唯一的觀點(diǎn)。第 24 條中將為你介紹，當(dāng)問題轉(zhuǎn)向“隱式類型轉(zhuǎn)換”時(shí)，選擇就在成員和非成員函數(shù)之間進(jìn)行）
需要關(guān)注的第二件事僅僅是由于：封裝要求函數(shù)不應(yīng)為類一個(gè)成員，而并不意味著要求它也不是其它類的成員。在某些語言中（比如 Eiffel 、 Java 、 C# 等等 ），所有函數(shù)必須包含在類中。對于習(xí)慣于使用這些語言的程序員來說，這第二件事多多少少可以算是對他們的一劑安撫藥。比如說，我們可以將 clearBrowser 定義為某個(gè)“實(shí)用工具類”中的靜態(tài)成員函數(shù)。只要它不是 WebBrowser 的一部分（或它的友元），它就不會影響到 WebBrowser 中私有成員的封裝性。
在 C++ 中可以使用一個(gè)更為自然的方法：將 clearBrowser 定義為一個(gè)非成員函數(shù)，并讓其與 WebBrowser 在同一個(gè)名字空間中：
namespace WebBrowserStuff {
class WebBrowser { ... };
void clearBrowser(WebBrowser& wb);
...
}
然而，你得到的東西遠(yuǎn)遠(yuǎn)要比更自然的代碼要多。因?yàn)榕c類不一樣的是，名字空間可以延伸至多個(gè)源代碼文件中。這一點(diǎn)十分重要。 ClearBrowser 這樣的函數(shù)是 “便利函數(shù)”。由于它們既不是成員函數(shù)也不是友元，所以它在訪問 WebBrowser 時(shí)就沒有任何特權(quán)，從而它也就不能夠以其它的什么辦法提供 WebBrowser 的客戶端代碼所不具備的功能。舉例說，如果 clearBrowser 不存在的話，那么客戶端就只能自己動手調(diào)用 clearCache 、 clearHistory 和 removeCookies 這些函數(shù)了。
一個(gè)類似 WebBrowser 的類可能會有大量的便利函數(shù)，一些是關(guān)于書簽的，另一些是關(guān)于打印的，還有關(guān)于 cookie 管理的，等等。作為一個(gè)一般守則，大多數(shù)客戶端只會對這些便利函數(shù)中的一部分感興趣。舉例說，一個(gè)客戶端程序員可能只對與書簽相關(guān)的便利函數(shù)感興趣，但是書簽相關(guān)便利函數(shù)又依賴于 cookie 相關(guān)的便利函數(shù)，沒有理由讓這個(gè)程序員去關(guān)心那些額外信息。將著些便利函數(shù)分離開來的最直接的辦法就是：將書簽相關(guān)的便利函數(shù)聲明在一個(gè)頭文件中， cookie 相 關(guān)的為與另一個(gè)頭文件，打印相關(guān)的在第三個(gè)：
// header "webbrowser.h" — 為 WebBrowser 自身所定義的頭文件
// 同時(shí)也包含“核心的” WebBrowser 相關(guān)的功能
namespace WebBrowserStuff {
class WebBrowser { ... };
... // “核心”相關(guān)功能
// 比如大多數(shù)客戶端必需的非成員函數(shù)
}
// header "webbrowserbookmarks.h"
namespace WebBrowserStuff {
... // 書簽相關(guān)的便利函數(shù)
}
// header "webbrowsercookies.h"
namespace WebBrowserStuff {
... // cookie 相關(guān)的便利函數(shù)
}
...
請注意：上面就是 C++ 標(biāo)準(zhǔn)庫的組織方式。標(biāo)準(zhǔn)庫使用了多個(gè)頭文件（包括 <vector> 、 <algorithm> 、 <memory> 等等），每一個(gè)都聲明了 std 名字空間中的某一些功能。而不是使用單態(tài)的 <C++StandardLibrary> 頭文件，并將 std 中所有的功能都羅列于此。對于僅希望使用 vector 相關(guān)功能的客戶端程序員，不應(yīng)該強(qiáng)迫他們?nèi)?/span> #include <memory> ；不希望使用 list 的客戶端也不需要去 #include <list> 。這樣就使得所有的客戶端程序員僅僅需要考慮他們正在使用的那部分系統(tǒng)中的編譯依賴問題。（參見第 31 條，其中介紹了解決減緩編譯依賴問題的其它途徑。）對于一個(gè)類的成員函數(shù)而言，以這種方式 分開管理功能是不可行的，因?yàn)橐粋€(gè)類必須要保證其完整性，它不應(yīng)該被分割成塊。
將所有的便利函數(shù)放置于多個(gè)頭文件中（但位于同一個(gè)名字空間中），同時(shí)也意味著客戶端程序員可以方便地?cái)U(kuò)展便利函數(shù)集。他們所需要做的僅僅是向同一名字空間中添加更多的非成員非友元函數(shù)。比如說，如果一個(gè) WebBrowser 的客戶端程序員希望編寫一個(gè)關(guān)于下載圖片的便利函數(shù)，他或她僅僅需要 在 WebBrowserStuff 名字 空間中創(chuàng)建一個(gè)新的頭文件來聲明這些函數(shù)。新的函數(shù)與其它的便利函數(shù)一樣可用，一樣具有整合性。這是類無法提供的又一特性，因?yàn)轭惗x并不為客戶端程序員提供擴(kuò)展性。當(dāng)然，客戶端程序員可以派生新類，但是派生類仍無法訪問基類中的封裝（也就是私有）成員，所以我們說這樣的“擴(kuò)展功能”只有“二等”身份。同時(shí)，如同第 7 條中所講，并不是所有的類都設(shè)計(jì)成了基類。
銘記在心
l 在特性情況下要更趨向于使用非成員非友元函數(shù)，而不是成員函數(shù)。這樣做可以增強(qiáng)封裝性，以及包裝的靈活性和功能擴(kuò)展性。