Effective C++——条款23(第4章)

条款23:    宁以non-member,non-friend 替换member函数

Prefer non-member non-friend functions to member functions

    想象有个 class 用来表示网页浏览器,这样的 class 可能提供众多函数,如下所示:

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函数clearEverything还是non-member函数clearBrowser?
    面向对象守则要求,数据以及操作数据的那些函数应该被捆绑在一起,这意味它建议member函数是较好的选择.不幸的是这个建议不正确.面向对象守则要求数据应该尽可能被封装,然而与直观相反,member函数clearEverything带来的封装性比non-member函数clearBrowser低.此外,提供non-member函数可允许对WebBrowser相关机能有较大的包括弹性,而那最终导致较低的编译相依度,增加WebBrowser的可延展性.因此许多方面non-member做法比member做法好.
    从封装开始讨论.如果某些东西被封装,它就不再可见.愈多东西被封装,愈少人可以看到它.而愈少人看到它,就有愈大的弹性去变化它,因为改变仅仅直接影响看到改变的那些事物.因此这就是封装重要的一个原因:它使得能够改变事物而只影响有限客户.
    考虑对象内的数据,愈少代码可以看到数据(访问它),愈多的数据可被封装.如何测量"有多少代码可以看到某一块数据"呢?计算能够访问该数据的函数数量,作为一种粗糙的测量.愈多函数可访问它,数据的封装性就愈低.
    条款22指出,成员变量应该是 private,如果它们不是,就有无限量的函数可以访问它们,它们就毫无封装性.能够访问 private 成员变量的函数只有 class 的member函数加上 friend 函数而已.如果在一个member函数和一个non-member,non-friend 函数之间做抉择,而且两者提供相同的机能,那么导致较大封装性的是non-member non-friend 函数,因为它并不增加"能够访问class内的private成分"的函数数量.这也就解释了clearBrowser(non-member non-friend 函数)比clearEverything(member函数)更受欢迎:它导致WebBrowser class 有较大的封装性.
    在这一点有两件事值得注意.第一,这个论述只适用于non-member non-friend 函数.第二,封装性让函数"成为class的non-member",并不意味着它"不可以是另一个class的member".例如可以令clearBrowser成为某工具类的一个 static member函数.只要它不是WebBrowser的一部分,就不会影响WebBrowser的 private 成员封装性.
    在C++,比较自然的做法是让clearBrowser成为一个non-member函数并且位于WebBrowser所在的同一个 namespace 内:

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

    然而,这不只是为了看起来自然而已.要知道 namespace 和 class 不同,前者可跨越多个源码文件而后者不能.因为像clearBrowser这样的函数是个"提供便利的函数",如果它既不是members也不是 friend,就没有对WebBrowser的特殊访问权力,也就不能提供"WebBrowser客户无法以其他方式取得"的机能.举个例子,如果clearBrowrer不存在,客户端只好自行调用clearCache,clearHistory和removeCookie.
    一个像WebBrowser这样的 class 可能拥有大量便利函数,例如某些与书签相关,某些与cookie管理有关...通常客户只对其中某些感兴趣.没道理一个只对书签相关便利函数感兴趣的客户却与一个cookie相关便利函数发生编译相依关系.分离它们的最直接做法是将书签相关便利函数声明于一个头文件,将cookie相关便利函数声明于另一个头文件...依次类推:

// 头文件"webbrowser.h"--这个头文件针对class WebBrowser自身以及WebBrowser核心机能namespace WebBrowserStuff {    class WebBrowser { ... };    ...        // 核心机能,例如几乎所有客户都需要的non-member函数}// 头文件"webbrowserbookmark.h"namespace WebBrowserStuff {    ...        // 与书签相关的便利函数}// 头文件"webbrowsercookies.h"namespace WebBrowserStuff {    ...        // 与cookie相关的便利函数}

    注意,这正是C++标准程序库的组织方式.标准程序库有数十个头文件(<vector>,<algorithm>,<memory>等等),每个头文件声明std的某些机能.如果客户只想使用vector相关机能,他不需要#include<memory>.如果客户不想使用list,也不需要#include<list>.这允许客户只对他们所用的那一部分系统形成编译相依(详见条款31,其中讨论降低编译依存性的其他做法).以这种方式切割机能并不适用于 class 成员函数,因为 class 必须整体定义,不能被分割为片片断断.
    将所有便利函数放在多个头文件但隶属于同一个命名空间,意味着客户可以轻松扩展这一组便利函数.他们需要做的就是添加更多non-member non-friend 函数到此命名空间内.例如,如果某个WebBrowser客户决定写些与影像下载相关的便利函数,只需要在WebBrowserStuff命名空间内建立一个头文件,内含那些函数的声明即可.新函数就像其他旧有的便利函数那样可用且整合为一体.这是 class 无法提供的另一个性质,因为 class 定义式对客户而言是不能扩展的.
    注意:
    宁可拿non-member non-friend 函数替换member函数.这样做可以增加封装性,包裹弹性和机能扩充性.