首页 > 代码库 > 《Effective C++》学习笔记——条款23

《Effective C++》学习笔记——条款23

2024-08-10 00:58:16   218人阅读

***************************************转载请注明出处：http://blog.csdn.net/lttree********************************************

 

 

 

四、Designs and Declarations



 

Rule 23：Prefer non-member non-friend fuctions to member functions

规则 23：宁以  non-member 、 non-friend 替换 member 函数



 


1.选哪个？

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

<span style="color:#666666;">class WebBrowser  {
public:
    ...
    void clearCache();
    void clearHistory();
    void removeCookies();
    ...
}</span>


这是基础的程序，嗯。。调用三个是不是有些太繁琐，所以WebBrowser也可能会提供一个，调用这三个的函数：


<span style="color:#666666;">class WebBrowser  {
public:
    ...
    void clearEverything( );    // 调用两个clear和romove函数
    ...
};</span>


当然这个机能也可由一个 non-member函数调用适当的member函数而提供：
<span style="color:#666666;">void clearBrowser( WebBrowser& wb )
{
    wb.clearCache();
    wb.clearHistory();
    wb.removeCookies();
}</span>


那么，问题来了！ 学技术哪家强？ （好老的梗啊。。。）

问题是，这两个哪个更好呢？



2.选哪个？

面向对象守则要求：数据以及操作数据的那些函数应该被捆绑在一起，这意味着它建议member函数是较好的选择。

不幸的是，这个建议不正确！

这是基于面向对象真实意义的一个误解。

面向对象守则要求数据应该尽可能被封装。然而与直观的相反地，member函数 clearEverything带来的封装性比 non-member函数 clearBrowser低。

此外，提供non-member函数可允许对WebBrowser相关机能有较大的包裹弹性，而那最终导致较低的编译相依度，增加WebBrowser的可延伸性。

因此，在许多方面 non-member 做法 比member做法好。



3.原因

让我们从封装开始讨论吧。

我们推崇封装的原因——它使我们改变事物而只影响有限客户。

而越多的函数能够访问对象内的数据，我们就判定它数据的封装性越低。

> 条款22曾描述过，成员变量应该是private，因为如果不是private，它就会被无限量的函数访问，等同于毫无封装性。

? 能访问private的函数 只有 class的member函数加上friend函数而已。

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

这就解释了为什么，上面例子 clearBrowser比clearEverything更受欢迎。

> 在此处要注意两件事：

?1、这个论述只适用于 non-member、non-friend函数。从封装的角度看，这里选择的关键并不在member函数和non-member函数之间，而是在member函数和 non-member、non-friend函数之间。

?2、只因在意其封装性而让函数“成为class的non-member”并不意味着它“不可以是另一个class的member”。我们可以令clearBrowser成为工具类（utility class）的一个 static member函数，只要它不是WebBrowser的一部分（或成为其friend），就不会影响WebBrowser的private成员封装性。



4.怎么做

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

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

然而，namespace 和 classes不同，namespace可以跨越多个源码文件但class不能。

这点非常重要，因为像例子中的 clearBrowser这样的函数是一个“提供便利的函数”，如果它既不是member函数 也不是friend函数，那它就没有对WebBrowser的特殊访问权利，也就不能提供“WebBrowser客户无法以其他方式取得”的机能。


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

// 头文件 "webbrowser.h"——这个头文件针对class WebBrowser自身及WebBrowser的核心机能
namespace WebBrowserStuff  {
class WebBrowser  {  ...  };
    ...   // 核心机能
}

// 头文件 “webbrowserbookmarks.h”
namespace WebBrowserStuff  {
    ...    // 与书签相关的便利函数
}

// 头文件“webbrowsercookies.h”
namespace WebBrowserStuff  {
    ...    // 与cookie相关的便利函数
}
...


5.还需要注意一些....

?上面所描述的，多个头文件的方式，正是C++标准程序库的组织方式。

?标准程序库并不是拥有单一、整体、庞大的<C++StandardLibrary>头文件并在其中内含std命名空间内的每一样东西，而是有数十个头文件（<vector>,<algorithm>,<memory>等等），每个头文件声明std的某些机能。如果客户只想使用vector相关机能，他不需要 #include <memory>; 如果客户不想用list，也不需要 #include <list>。

?这允许客户只对他们所用的那一小部分系统形成编译相依，以此种方式切割机能并不适用于class成员函数，因为一个class必须整体定义，不能被分割为片片段段。

?将所有便利函数放在多个头文件内但隶属于同一个命名空间，这意味着客户可以轻松扩展这一组便利函数。他们需要做的就是添加更多的 non-member、non-friend函数到此命名空间内。新函数就像其他旧有的便利函数那样可用且整合为一体。这是class无法提供的另一个性质。因为class定义式对客户而言是不能扩展的。

? 但是，客户可以派生出新的class，但派生类无法访问基类中被封装的成员，于是如此的“扩展机能”只有次级身份。此外，正如条款7所说，并非所有class都被设计用来做base class。



6.请记住

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





***************************************转载请注明出处：http://blog.csdn.net/lttree********************************************

《Effective C++》学习笔记——条款23


联系
我们