想象一个象征 web 浏览器的类。在大量的函数中，这样一个类也许会提供清空已下载成分的缓存。清空已访问 URLs 的历史，以及从系统移除所有 cookies 的功能：
class WebBrowser {
public:
...
void clearCache();
void clearHistory();
void removeCookies();
...
};
很多用户希望能一起执行全部这些动作，所以 WebBrowser 可能也会提供一个函数去这样做：
class WebBrowser {
public:
...
void clearEverything(); // calls clearCache, clearHistory,
// and removeCookies
...
};
当然，这个功能也能通过非成员函数调用适当的成员函数来提供：
void clearBrowser(WebBrowser& wb)
{
wb.clearCache();
wb.clearHistory();
wb.removeCookies();
}
那么哪个更好呢，成员函数 clearEverything 还是非成员函数 clearBrowser？
面性对象原则指出：数据和对它们进行操作的函数应该被绑定到一起，而且建议成员函数是更好的选择。不幸的是，这个建议是不正确的。它产生于对面向对象是什么的一个误解。面向对象原则指出数据应该尽可能被封装。与直觉不同，成员函数 clearEverything 居然会造成比非成员函数 clearBrowser 更差的封装性。此外，提供非成员函数允许 WebBrowser 相关功能的更大的包装弹性，而且，可以获得更少的编译依赖和 WebBrowser 扩展性的增进。因而，在很多方面非成员方法比一个成员函数更好。理解它的原因是非常重要的。
我们将从封装开始。如果某物被封装，它被从视线中隐藏。越多的东西被封装，就越少有东西能看见它。越少有东西能看见它，我们改变它的弹性就越大，因为我们的改变仅仅直接影响那些能看见我们变了什么的东西。某物的封装性越强，那么我们改变它的能力就越强。这就是将封装的价值评价为第一的原因：它为我们提供一种改变事情的弹性，而仅仅影响有限的客户。
结合一个对象考虑数据。越少有代码能看到数据（也就是说，访问它），数据封装性就越强，我们改变对象的数据的特性的自由也就越大，比如，数据成员的数量，它们的类型，等等。作为多少代码能看到一块数据的粗糙的尺度，我们可以计数能访问那块数据的函数的数量：越多函数能访问它，数据的封装性就越弱。
数据成员应该是 private 的，因为如果它们不是，就有无限量的函数能访问它们。它们根本就没有封装。对于 private 数据成员，能访问他们的函数的数量就是类的成员函数的数量加上友元函数的数量，因为只有成员和友元能访问 private 成员。假设在一个成员函数（能访问的不只是一个类的 private 数据，还有 private 函数，枚举，typedefs，等等）和一个提供同样功能的非成员非友元函数（不能访问上述那些东西）之间有一个选择，能获得更强封装性的选择是非成员非友元函数，因为它不会增加能访问类的 private 部分的函数的数量。这就解释了为什么 clearBrowser（非成员非友元函数）比 clearEverything（成员函数）更可取：它能为 WebBrowser 获得更强的封装性。
在这一点，有两件事值得注意。首先，这个论证只适用于非成员非友元函数。友元能像成员函数一样访问一个类的 private 成员，因此同样影响封装。从封装的观点看，选择不是在成员和非成员函数之间，而是在成员函数和非成员非友元函数之间。（当然，封装并不是仅有的观点，如果观点来自隐式类型转换，选择就是在成员和非成员函数之间。）
需要注意的第二件事是，如果仅仅是为了关注封装，则可以指出，一个函数是一个类的非成员并不意味着它不可以是另一个类的成员。这对于习惯了所有函数必须属于类的语言（例如，Eiffel，Java，C#，等等）的程序员是一个适度的安慰。例如，我们可以使 clearBrowser 成为一个 utility 类的 static 成员函数。只要它不是 WebBrowser 的一部分（或友元），它就不会影响 WebBrowser 的 private 成员的封装。
在 C++ 中，一个更自然的方法是使 clearBrowser 成为与 WebBrowser 在同一个 namespace（名字空间）中的非成员函数：