Effective C++设计声明之（宁以non-member、non-friend替换member函数）

Effective C++设计声明之（宁以non-member、non-friend替换member函数）

问题聚焦:

• member函数的封装一定比 non-member、non-friend好吗？并不是
• 导致较大封装性的可能是non-member non-friend函数，因为它并不增加“能够访问class内之private成分”的函数数量。

假设有个class用来表示网页浏览器。这样的class可能提供的众多函数中，有一些用来清除下载元素高速缓存区、清除访问过的URLs的历史记录、以及移除系统中的所有cookies：

class WebBrowser {
public:
	void clearCache();
    void clearHistory();
    void removeCookies();
};

许多用户会想以整个执行所有这些动作，因此WebBrowser也提供这样一个函数：

class WebBrowser {
public:
     void clearEverything();//调用clearCache,clearHistory,removeCookies
};

当然，这一机能也可由一个non-member函数调用适当的member函数而提供出来：

void clearBrowser(WebBrowser& wb)
{
    wb.clearCache();
    wb.clearHistory();
    wb.removeCookies();
}

问题：这两种方式哪一个比较好呢？

• 面向对象守则要求，数据以及操作数据的那些函数应该被捆绑在一块，这意味它建议member函数是较好的选择。不幸的是这个建议不正确。这是基于对面向对象真实意义的一个误解。
• 面向对象守则要求数据应该尽可能被封装，然后与直观相反地，member函数clearEverything带来的封装性比non-member函数clearBrowser低。
• 此外，提供non-member函数可允许对WebBrowser相关机能有较大的包裹弹性，而那最终导致较低的编译相依度，增加WebBrowser的可延伸性。因此在许多方面non-member做法比member做法好。

原因：

• 对于封装：如果某些东西被封装，它就不再可见。越多东西被封装，越少人可以看见它。而越少人看见它，我们就有越大的弹性去变化它，因为我们的改变仅仅直接影响看到改变的那些人事物。因此，越多东西被封装，我们改变那些东西的能力也及越大。这就是我们首先推崇封装的原因：它使我们能够改变事物而只影响有限客户。

• 对于对象内的数据：越少代码可以看到数据（也就是访问它），越多的数据可被封装，而我们也就越能自由地改变对象数据，例如改变成员变量的数量、类型等等。越多函数可访问它，数据的封装性就越低。

• 成员变量应该是private，因为如果它们不是，就有无限量的函数可以访问它们，它们也就毫无封装性。能够访问private成员变量的函数只有class member函数加上friend函数而已。

• 如果要在一个member函数（它不只可以访问class内的private数据，也可以取用private函数、enum、typedef等等）和一个non-member，non-friend函数之间做选择，而且两者提供相同机能，那么，导致较大封装性的是non-member non-friend函数，因为它并不增加“能够访问class内之private成分”的函数数量。

这就解释了为什么clearBrowser（一个non-member non-friend函数）比clearEverything（一个member函数）更受欢迎的原因：它导致WebBrowser class有较大的封装性。

在C++，比较自然的做法是让clearBrowser成为一个non-member函数并且位于WebBrowser所在同一个namespace内：

namespace WebBrowserStuff {
        class WebBrowser {};
        void clearBrowser(WebBrowser& wb);
}

分离做法：

//头文件“webbrowser.h”针对class WebBrowser自身及WebBrowser核心机能
namespace WebBrowserStuff {
class WebBrowser {
//核心机能，几乎所有客户都需要的non-member函数
};
}
 
//头文件“webbrowserbookmarks.h”
namespace WebBrowserStuff {
//与书签相关的便利函数
}
 
//头文件“webbrowsercookies.h”
namespace WebBrowserStuff {
//与cookies相关的便利函数
}

将所有便利函数放在多个头文件内但隶属同一个命名空间，意味客户可以轻松扩展这一组便利函数。他们需要做的就是添加更多non-member non-friend函数到此命名空间内。比如，如果某个WebBrowser客户决定写些与影像下载相关的便利函数，他只需在WebBrowserStuff命名空间内建立一个头文件，内含那些便利函数的声明即可。

小结：

• 宁可拿non-member non-friend函数替换member函数。这样做可以增加封装性、包裹弹性（packaging flexibility）和机能扩充性。