請假想一個表示網頁瀏覽器的類。這個類可以提供諸多功能，其中包括清除下載緩存、清除訪問歷史、刪除系統中保存的cookie等等：
class WebBrowser {
public:
...
void clearCache();
void clearHistory();
void removeCookies();
...
};
許多用戶可能需要同時執行這些操作，所以WebBrowser類應該提供一個函數來做這件事情：
class WebBrowser {
public:
...
void clearEverything(); // 調用clearCache、clearHistory
// 以及removeCookies
...
};
當然，這一功能也可以通過使用一個非成員函數調用適當的成員函數來實現：
void clearBrowser(WebBrowser& wb)
{
wb.clearCache();
wb.clearHistory();
wb.removeCookies();
}
哪一個更好呢？是成員函數clearEverything，還是非成員函數clearBrowser？
面向對象的基本原理要求數據和對其進行操作的函數應該被包裝在一起，同時建議成員函數為更優秀的選擇。但不幸的是，這一建議并不是正確的。它是建立在對“面向對象的東西意味著什么”這一點的誤解之上的。面向對象的基本原理要求數據應該盡可能的被封裝起來。通過理性分析可以得知，成員函數clearEverything的封裝性實際上比非成員函數clearBrowser還要差。還有，非成員函數可以為WebBrowser相關的功能提供更便利的打包方法，從而減少編譯時依賴，提高WebBrowser的可擴展性。很多情況下，非成員函數的方法都比成員函數的方法要好。理解這一結論的原因是十分重要的。
我們從封裝問題開始。如果一個物件被封裝了，那么它就是不可見的。它的封裝度越高，其它人或物件能看到它的機會就越少。能看到它的東西越少，我們對其進行修改的靈活性就越高，因為只有很少的物件能看到我們的改動。也就是說，一個物件的封裝度越高，系統賦予我們修改它的能力就越強。這就是我們為什么將封裝置于首要位置的原因：他為我們提供了改變物件的靈活性的方法，使用這一方法只會有很少的客戶會受到影響。
請考慮與對象相關的數據。可以看到（也就是訪問）某一數據的代碼越少，就有更多的數據被封裝起來，從而我們修改這一對象的數據特征（比如數據成員的個數、類型等等）時就更為自由，粗略計算一下某一數據可以被多少代碼所訪問，我們就可以計算出有多少函數可以訪問這一數據：可以訪問它的函數越多，這一數據的封裝度就越低。
條目22中解釋了數據成員為什么要聲明為私有的，因為如果不這么做，那么就有無窮的函數可以訪問它們。它們就毫無封裝性可言。對于聲明為私有的數據成員來說，可以訪問它們的函數的個數就等于成員函數的個數加上友元函數的個數，因為只有成員和友元可以訪問類中的私有數據。無論是成員函數（不僅僅可以訪問類中的私有數據，還可以訪問私有函數、enum類型、由typedef生成的類型符號，等等）還是非成員非友元函數（上述成員函數可以訪問的所有內容都不可訪問）所提供的功能都是完全相同的，選擇非成員非友元函數可以帶來更完整的封裝度，因為它不會使可以訪問類中私有部分函數的數量增加。這就解釋了為什么使用clearBrowser（非成員非友元函數）比clearEverything（成員函數）更理想：clearBrowser可以為WebBrowser類提供更高的封裝度。
此刻我們需要注意兩件事情。第一，上面的推理過程僅僅適用于非成員非友元函數。由于友元對類中的私有成員的訪問權與成員函數相仿，因此使用友元對封裝度帶來的影響與成員函數是一致的。如果充分考慮封裝的因素，我們并不是在成員或非成員函數之間做出選擇，而是成員函數和非成員非友元函數之間做出選擇。（當然，封裝也不是唯一需要考慮的因素。條目24中將為你介紹，當問題轉向“隱式類型轉換”時，選擇就在成員和非成員函數之間進行。）
需要關注的第二件事僅僅是由于：封裝要求函數不應為類一個成員，而并不意味著要求它也不是其它類的成員。在某些語言中（比如Eiffel、Java、C#等等），所有函數必須包含在類中。對于習慣于使用這些語言的程序員來說，這第二件事多多少少可以算是對他們的一劑安撫藥。比如說，我們可以將clearBrowser定義為某個“實用工具類”中的靜態成員函數。只要它不是WebBrowser的一部分（或它的友元），它就不會影響到WebBrowser中私有成員的封裝性。
在C++中可以使用一個更為自然的方法：將clearBrowser定義為一個非成員函數，并將其與WebBrowser放置在同一個名字空間中：
namespace WebBrowserStuff {
class WebBrowser { ... };
void clearBrowser(WebBrowser& wb);
...
}
然而，你得到的東西遠遠要比更自然的代碼要多。因為與類不一樣的是，名字空間可以延伸至多個源代碼文件中。這一點十分重要。ClearBrowser這樣的函數是“便利函數”。由于它們既不是成員函數也不是友元，所以它在訪問WebBrowser時就沒有任何特權，從而它也就不能夠以其它的什么辦法提供WebBrowser的客戶端代碼所不具備的功能。舉例說，如果clearBrowser不存在的話，那么客戶就只能自己動手調用clearCache、clearHistory和removeCookies這些函數了。
一個類似WebBrowser的類可能會有大量的便利函數，一些是關于書簽的，另一些是關于打印的，還有關于cookie管理的，等等。作為一個一般守則，大多數客戶只會對這些便利函數中的一部分感興趣。舉例說，一個客戶可能只對與書簽相關的便利函數感興趣，但是書簽相關便利函數又依賴于cookie相關的便利函數，沒有理由讓這個程序員去關心那些額外信息。將著些便利函數分離開來的最直接的辦法就是：將書簽相關的便利函數聲明在一個頭文件中，cookie相關的為與另一個頭文件，打印相關的在第三個：
// 頭文件 "webbrowser.h" — 為WebBrowser自身所定義的頭文件
// 同時也包含“核心的” WebBrowser相關的功能
namespace WebBrowserStuff {
class WebBrowser { ... };
... // “核心”相關功能
// 比如幾乎所有客戶所需的非成員函數
}
// 頭文件 "webbrowserbookmarks.h"
namespace WebBrowserStuff {
... // 書簽相關的便利函數
}
// 頭文件 "webbrowsercookies.h"
namespace WebBrowserStuff {
... // cookie相關的便利函數
}
...
請注意：上面就是C++標準庫的組織方式。標準庫使用了多個頭文件（包括<vector>、<algorithm>、<memory>等等），每一個都聲明了std名字空間中的某一些功能。而不是使用單一的、龐大的<C++StandardLibrary>頭文件，并將std中所有的功能都羅列于此。對于僅希望使用vector相關功能的客戶，不應該強迫他們去#include <memory>；不希望使用list的客戶端也不需要去#include <list>。這樣就使得所有客戶僅僅需要考慮他們正在使用的那部分系統中的編譯依賴問題。（參見條目31，其中介紹了解決減緩編譯依賴問題的其它途徑。）讓我們重新考慮成員函數的方案，以這種方式分開管理功能是不可行的，因為一個類必須要保證其完整性，它不能夠被分割成塊。
將所有的便利函數放置于多個頭文件中（但位于同一個名字空間中），同時也意味著客戶可以方便地擴展便利函數集。他們所需要做的僅僅是向同一名字空間中添加更多的非成員非友元函數。比如說，如果一個WebBrowser的客戶希望編寫一系列用于下載圖片的便利函數，他或她僅僅需要在WebBrowserStuff名字空間中創建一個新的頭文件來聲明這些函數。新的函數與其它的便利函數一樣可用，一樣具有整合性。這是類無法提供的又一特性，因為類定義并不為客戶提供擴展性。當然，客戶可以派生新類，但是派生類仍無法訪問基類中的封裝（即私有）成員，所以我們說這樣的“擴展功能”只有“二等”身份。同時，如同條目7中所講，并不是所有的類都設計成了基類。
時刻牢記
l 多用非成員非友元函數，少用成員函數。這樣做可以增強封裝性，以及包裝的靈活性和功能的擴展性。