C 箴言:用非成员非友元函数取代成员函数

　　想象一个象征 web 浏览器的类。在大量的函数中，这样一个类也许会提供清空已下载成分的缓存。清空已访问 URLs 的历史，连同从系统移除任何 cookies 的功能：

class WebBrowser {
　public:
　　...
　　void clearCache();
　　void clearHistory();
　　void removeCookies();
　　...
};

　　很多用户希望能一起执行全部这些动作，所以 WebBrowser 可能也会提供一个函数去这样做：

class WebBrowser {
　public:
　　...
　　void clearEverything(); // calls clearCache, clearHistory,
　　// and removeCookies
　　...
};

　　当然，这个功能也能通过非成员函数调用适当的成员函数来提供：

void clearBrowser(WebBrowser& wb)
{
　wb.clearCache();
　wb.clearHistory();
　wb.removeCookies();
}

　　那么哪个更好呢，成员函数 clearEverything 还是非成员函数 clearBrowser？

　　面性对象原则指出：数据和对他们进行操作的函数应该被绑定到一起，而且建议成员函数是更好的选择。不幸的是，这个建议是不正确的。他产生于对面向对象是什么的一个误解。面向对象原则指出数据应该尽可能被封装。和直觉不同，成员函数 clearEverything 居然会造成比非成员函数 clearBrowser 更差的封装性。此外，提供非成员函数允许 WebBrowser 相关功能的更大的包装弹性，而且，能够获得更少的编译依赖和 WebBrowser 扩展性的增进。因而，在很多方面非成员方法比一个成员函数更好。理解他的原因是很重要的。

　　我们将从封装开始。假如某物被封装，他被从视线中隐藏。越多的东西被封装，就越少有东西能看见他。越少有东西能看见他，我们改变他的弹性就越大，因为我们的改变仅仅直接影响那些能看见我们变了什么的东西。某物的封装性越强，那么我们改变他的能力就越强。这就是将封装的价值评价为第一的原因：他为我们提供一种改变事情的弹性，而仅仅影响有限的客户。

　　结合一个对象考虑数据。越少有代码能看到数据（也就是说，访问他），数据封装性就越强，我们改变对象的数据的特性的自由也就越大，比如，数据成员的数量，他们的类型，等等。作为多少代码能看到一块数据的粗糙的尺度，我们能够计数能访问那块数据的函数的数量：越多函数能访问他，数据的封装性就越弱。

　　数据成员应该是 private 的，因为假如他们不是，就有无限量的函数能访问他们。他们根本就没有封装。对于 private 数据成员，能访问他们的函数的数量就是类的成员函数的数量加上友元函数的数量，因为只有成员和友元能访问 private 成员。假设在一个成员函数（能访问的不只是个类的 private 数据，更有 private 函数，枚举，typedefs，等等）和一个提供同样功能的非成员非友元函数（不能访问上述那些东西）之间有一个选择，能获得更强封装性的选择是非成员非友元函数，因为他不会增加能访问类的 private 部分的函数的数量。这就解释了为什么 clearBrowser（非成员非友元函数）比 clearEverything（成员函数）更可取：他能为 WebBrowser 获得更强的封装性。

　　在这一点，有两件事值得注意。首先，这个论证只适用于非成员非友元函数。友元能像成员函数相同访问一个类的 private 成员，因此同样影响封装。从封装的观点看，选择不是在成员和非成员函数之间，而是在成员函数和非成员非友元函数之间。（当然，封装并不是仅有的观点，假如观点来自隐式类型转换，选择就是在成员和非成员函数之间。）

　　需要注意的第二件事是，假如仅仅是为了关注封装，则能够指出，一个函数是个类的非成员并不意味着他不能够是另一个类的成员。这对于习惯了任何函数必须属于类的语言（例如，Eiffel，Java，C#，等等）的程式员是个适度的安慰。例如，我们能够使 clearBrowser 成为一个 utility 类的 static 成员函数。只要他不是 WebBrowser 的一部分（或友元），他就不会影响 WebBrowser 的 private 成员的封装。

　　在 C 中，一个更自然的方法是使 clearBrowser 成为和 WebBrowser 在同一个 namespace（名字空间）中的非成员函数：

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

　　相对于形式上的自然，这样更适用于他。无论如何，因为名字空间（不像类）能展开到多个源文档中。这是很重要的，因为类似 clearBrowser 的函数是方便性函数。作为既不是成员也不是友元，他们没有对 WebBrowser 进行专门的访问，所以他们不能提供任何一种 WebBrowser 的客户不能通过其他方法得到的功能。例如，假如 clearBrowser 不存在，客户能够直接调用 clearCache，clearHistory 和 removeCookies 本身。

　　一个类似 WebBrowser 的类能够有大量的方便性函数，一些是书签相关的，另一些打印相关的，更有一些是 cookie 管理相关的，等等。作为一个一般的惯例，多数客户仅对这些方便性函数的集合中的一些感兴趣。没有理由让一个只对书签相关的方便性函数感兴趣的客户在编译时依赖其他函数，例如，cookie 相关的方便性函数。分隔他们的直截了当的方法就是在一个头文档中声明书签相关的方便性函数，在另一个不同的头文档中声明 cookie 相关的方便性函数，在第三个头文档声明打印相关的方便性函数，等等：

// header "webbrowser.h" - header for class WebBrowser itself
// as well as "core" WebBrowser-related functionality
namespace WebBrowserStuff {

　class WebBrowser { ... };
　... // "core" related functionality, e.g.
　// non-member functions almost
　// all clients need
}
// header "webbrowserbookmarks.h"
namespace WebBrowserStuff {
... // bookmark-related convenience
} // functions
// header "webbrowsercookies.h"
namespace WebBrowserStuff {
　... // cookie-related convenience

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有