宁以non-member、non-friend替换member函数——条款23

最新推荐文章于 2024-04-04 17:09:57 发布

OODeveloper

最新推荐文章于 2024-04-04 17:09:57 发布

阅读量320

点赞数

分类专栏： Effective C++ 文章标签： c++ 封装

本文链接：https://blog.csdn.net/yj_android_develop/article/details/105372759

版权

Effective C++ 专栏收录该内容

53 篇文章

订阅专栏

想象有个class用来表示网页浏览器。这样的class可能提供的众多函数中，有一些用来消除下载元素高速缓存区（cache of download elements）、清除访问过的URLs的历史记录（history of visited 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函数clearEverything还是non-member函数clearBrowser？

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

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

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

条款22曾说过，成员变量应该是private，因为如果它们不是，就有无限量的函数可以访问它们，它们也就毫无封装性。能够访问private成员变量的函数只有class的member函数加上friend函数而已。这就解释为什么clearBrowser（一个non-member、non-friend函数）比clearEverything（一个member函数）更受欢迎的原因：它导致WebBrowser class有较大的封装性。

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

第一，这个论述只适用于non-member、non-friend函数。friend函数对class private成员的访问权力和member函数相同，因此两者对封装的冲击力道也相同。从封装角度看，这里的选择关键并不在member和non-member函数之间，而是在member和non-member、non-friend函数之间。（当然，封装并非唯一考虑。条款24解释当我们考虑隐式类型转换，应该在member和non-member函数之间抉择。）

第二件值得注意的事情是，只因在意封装性而让函数“成为class的non-member”，并不意味它“不可以是另一个class的member”。例如我们可以令clearBrowser成为某工具类（utility class）的一个static member函数。只要它不是WebBrowser的一部分（或成为其friend），就不会影响WebBrowser的private成员封装性。

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

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

然而这不只是为了看起来自然而已，要知道，namespace和class不同，前者可跨越多个源码文件，而后者不能。这很重要，一个像WebBrowser这样的class可能拥有大量便利函数，分离它们的最直接做法就是将书签相关便利函数声明于一个头文件，将cookie相关便利函数声明于另一个头文件，再将打印相关便利函数声明于第三个头文件，以此类推：

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

将所有便利函数放在多个头文件内，但隶属于同一个命名空间，意味客户可以轻松扩展这一组便利函数。他们需要做的就是添加更多non-member、non-friend函数到此命名空间内。举个例子，如果某个WebBrowser客户决定写些与影像下载相关的便利函数，他只需要在WebBrowserStuff命名空间内建立一个头文件，内含那些函数的声明即可。新函数就像其它旧有的便利函数那样可用且整合为一体。这是class无法提供的另一个性质，因为class定义式对客户而言是不能扩展的。当然，客户可以派生出新的classes，但derived classes无法访问base class中被封装的（即private）成员，于是如此的“扩展机能”拥有的只是次级身份。此外——如条款7所说，并非所有classes都被设计用来作为base classes。

请记住