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