***************************************转载请注明出处：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********************************************