C++条款宁以non-member、non-friend替换menber函数 14/55

最新推荐文章于 2022-01-29 20:17:12 发布

MisakiJh

最新推荐文章于 2022-01-29 20:17:12 发布

阅读量420

点赞数

分类专栏： C++条款

本文链接：https://blog.csdn.net/MisakiJh/article/details/89160135

版权

C++条款专栏收录该内容

13 篇文章 2 订阅

订阅专栏

宁以non-member、non-friend替换menber函数

Prefer non-member non-friend functions to member functions

想想有个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还是non-member？

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

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

现在考虑对象内的数据。愈少代码可以访问数据，愈多的数据可被封装，而我们也就越能自由地改变对象数据，例如改变成员变量的数量、类型等等。如何测量“有多少代码可以看到某一块数据”呢？我们计算能够访问该数据的函数数量，作为一种粗糙的测量。愈多函数可访问它，数据的封装性就愈低。

如果你在一个member函数和一个non-member、non-friend函数之间做选择，而且两者提供相同机能，那么，导致较大封装性的是non-member non-friend函数，因为它并不增加“能够访问class内之private成分”的函数数量。

在这一点上有两件事情值得注意：

这个论述只适用于non-member non-friend函数。friends函数对class private成员的访问权力和member函数相同，因此两者对封装的冲击力道也相同。从封装的角度看，这里选择的关键并不在memberhe non-member函数之间，而是在member和nono-member non-friend函数之间。
只因在意封装性而让函数“成为class的non-member”，并不意味着它“不可以是另一个class的member”。例如我们可以令clearBrowser成为某工具类的一个static member函数。只要它不是WebBrowser的一部分（或成为其friend），就不会影响WebBrowser的private成员封装性

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

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

namespace和classes不同，前者可跨越多个源码文件而后者不能。这很重要，因为像clearBrowser这样的函数是个“提供便利的函数”，如果它既不是members也不是friends，就没有对WebBrowser的特殊访问权力。

一个像WebBrowser这样的class可能拥有大量便利函数，通常大多数客户只对其中某些感兴趣。没道理一个只对书签相关便利函数感兴趣的客户与一个cookie相关便利函数发生编译相依关系。分离它们的最直接做法就是将书签相关便利函数声明于一个头文件，将cookie相关便利函数声明于另一个头文件，再将打印相关便利函数声明于第三个头文件，以此类推：

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

注意，这正是C++标准程序库的组织方式。标准程序库并不是拥有单一、整体、庞大的<C++StandardLibrary>头文件并在其中内含std命名空间内的每一样东西，而是有数十个头文件（<vector>, <algorithm>, <memory>），每个头文件声明std的某些机能。这允许客户只对他们所用的那一小部分系统形成编译相依。

将所有便利函数放在多个头文件内但隶属于一个命名空间，意味着客户可以轻松扩展这一组便利函数。他们需要做的就是添加更多non-member non-friend函数到此命名空间内。这个class无法提供的另一个性质，因为class定义式对客户而言是不能扩展的。当然客户可以派生出新的classes，但derived classes无法访问base class中被封装的成员。