Effective c++之Item 23: 用非成员非友元函数取代成员函数
想象一个象征 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 扩展性的增进。因而，在很多方面非成员方法比一个成员函数更好。理解它的原因是非常重要的。
我们将从封装开始。如果某物被封装，它被从视线中隐藏。越多的东西被封装，就越少有东西能看见它。越少有东西能看见它，我们改变它的弹性就越大，因为我们的改变仅仅直接影响那些能看见我们变了什么的东西。某物的封装性越强，那么我们改变它的能力就越强。这就是将封装的价值评价为第一的原因：它为我们提供一种改变事情的弹性，而仅仅影响有限的客户。
结合一个对象考虑数据。越少有代码能看到数据（也就是说，访问它），数据封装性就越强，我们改变对象的数据的特性的自由也就越大，比如，数据成员的数量，它们的类型，等等。作为多少代码能看到一块数据的粗糙的尺度，我们可以计数能访问那块数据的函数的数量：越多函数能访问它，数据的封装性就越弱。
Item 22 说明了数据成员应该是 private 的，因为如果它们不是，就有无限量的函数能访问它们。它们根本就没有封装。对于 private 数据成员，能访问他们的函数的数量就是类的成员函数的数量加上友元函数的数量，因为只有成员和友元能访问 private 成员。假设在一个成员函数（能访问的不只是一个类的 private 数据，还有 private 函数，枚举，typedefs，等等）和一个提供同样功能的非成员非友元函数（不能访问上述那些东西）之间有一个选择，能获得更强封装性的选择是非成员非友元函数，因为它不会增加能访问类的 private 部分的函数的数量。这就解释了为什么 clearBrowser（非成员非友元函数）比 clearEverything（成员函数）更可取：它能为 WebBrowser 获得更强的封装性。
在这一点，有两件事值得注意。首先，这个论证只适用于非成员非友元函数。友元能像成员函数一样访问一个类的 private 成员，因此同样影响封装。从封装的观点看，选择不是在成员和非成员函数之间，而是在成员函数和非成员非友元函数之间。（当然，封装并不是仅有的观点，Item 24 说明如果观点来自隐式类型转换，选择就是在成员和非成员函数之间。）
需要注意的第二件事是，如果仅仅是为了关注封装，则可以指出，一个函数是一个类的非成员并不意味着它不可以是另一个类的成员。这对于习惯了所有函数必须属于类的语言（例如，Eiffel，Java，C#，等等）的程序员是一个适度的安慰。例如，我们可以使 clearBrowser 成为一个 utility 类的 static 成员函数。只要它不是 WebBrowser 的一部分（或友元），它就不会影响 WebBrowser 的 private 成员的封装。
在 C++ 中，一个更自然的方法是使 clearBrowser 成为与 WebBrowser 在同一个 namespace（名字空间）中的非成员函数：
namespace WebBrowserStuff {
class WebBrowser { ... };
void clearBrowser(WebBrowser& wb);
...
}
相对于形式上的自然，这样更适用于它。无论如何，因为名字空间（不像类）能展开到多个源文件中。这是很重要的，因为类似 clearBrowser 的函数是方便性函数。作为既不是成员也不是友元，他们没有对 WebBrowser 进行专门的访问，所以他们不能提供任何一种 WebBrowser 的客户不能通过其它方法得到的功能(即没有方便性 函数，客户也能通过其他方法获得相同的功能)。例如，如果 clearBrowser 不存在，客户可以直接调用 clearCache，clearHistory 和 removeCookies 本身。
一个类似 WebBrowser 的类可以有大量的方便性函数，一些是书签相关的，另一些打印相关的，还有一些是 cookie 管理相关的，等等。作为一个一般的惯例，多数客户仅对这些方便性函数的集合中的一些感兴趣。没有理由让一个只对书签相关的方便性函数感兴趣的客户在编译时依赖其它函数，例如，cookie 相关的方便性函数。分隔它们的直截了当的方法就是在一个头文件中声明书签相关的方便性函数，在另一个不同的头文件中声明 cookie 相关的方便性函数，在第三个头文件声明打印相关的方便性函数，等等：
// header "webbrowser.h" - header for class WebBrowser itself
// as well as "core" WebBrowser-related functionality
namespace WebBrowserStuff {
class WebBrowser { ... };
... // "core" related functionality, e.g.
// non-member functions almost
// all clients need
}
// header "webbrowserbookmarks.h"
namespace WebBrowserStuff {
... // bookmark-related convenience
} // functions
// header "webbrowsercookies.h"
namespace WebBrowserStuff {
... // cookie-related convenience
} // functions
...
注意这里就像标准 C++ 库组织得一样严密。胜于有一个单独的一体式的 。这就允许客户在编译时仅仅依赖他们实际使用的那部分系统。（参见Item 31 对减少编译依赖的其它方法的讨论。）当机能来自一个类的成员函数时，用这种方法分割它是不可能的，因为一个类必须作为一个整体来定义，它不能四分五裂。
将所有方便性函数放入多个头文件中——但是在一个 namespace 中——也意味着客户能容易地扩充方便性函数的集合。他们必须做的全部就是在 namespace 中加入更多的非成员非友元函数。例如，如果一个 WebBrowser 的客户决定写一个关于下载图像的方便性函数，他或她仅仅需要新建一个头文件，包含那些函数在 WebBrowserStuff namespace 中的声明。这个新的函数现在就像其它方便性函数一样可用并被集成。这是类不能提供的另一个特性，因为类定义对于客户是扩充封闭的。当然，客户可以派生新类，但是派生类不能访问基类中被封装的（也就是说，private 的）成员，所以这样的“扩充机能”只有二等身份。此外，就像 Item 7 中解释的，不是所有的类都是作为基类设计的。
Things to Remember
· 用非成员非友元函数取代成员函数。这样做可以提高封装性，包装弹性，和机能扩充性。