C/C++编程：宁以non-member、non-friend替换member函数

本是古典何须时尚 2023-01-19 12:59 125阅读 0赞

# 引入 #

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

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

很多用户想一整个执行所有的这些动作，因此webBrowser也提供这样一个函数：

class WebBrower{
        
    public:
    	void clearEverything(); // 调用clearCache、clearHistory、removeCookies
    };

当然，这一功能也可由一个non-member函数调用适当的成员函数而提供出来：

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

问题是，哪一个比较好呢？

面向对象守则要求，数据以及操作数据的那些函数应该被捆绑在一块，这意味着它建议成员函数是比较好的选择。不幸的是这个建议不正确，这是基于对面向对象真实意义的一个误解。面向对象守则要求的是尽可能被封装，然而与直观相反的是，成员函数clearEverything()带来的封装性比non-member函数clearBrowser()低。此外，提供non-member函数可允许对WebBrowser相关功能有较大的包裹弹性。因此，在很多方面，non-member做法比member做法好

# 原因 #

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

*  成员函数应该时private。因为如果它们不是，就有无限量的函数可以去访问它们，它们也就毫无封装性。
 *  **能够访问private成员变量的只有类的成员函数和友元函数**

如果你要在一个成员函数和一个非成员非友元函数之间做选择，而且两者提供相同的功能，那么，较大封装性的是非成员非友元函数。也就是为什么clearBrowser更好的原因。

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

*  第一，这个论述只适用于non-member non-friend函数。友元函数对类private成员的访问权力和成员函数相同，因此两者对封装的冲击力道也相同。从封装的角度来看，这里选择的关键并不在member和non-member函数之间，而是在member和non-member non-friend函数之间
 *  第二，只因在意封装性而让函数"成为类的non-member"，并不意味着它"不可以是另一个类的成员"。因此，我们可以令clearBrowser成为某个工具类的一个static member函数，只要它不是webBrowser的一部分(或者成为友元)，就不会影响WebBrowser的private成员封装性

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

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

一些像WebBrower这样的类可能有大量便利函数，某些与书签有关，某些与打印有关，有些与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>、< list>等等，每个头文件声明std的某些机能。如果客户只想要vector相关功能，就只需要\#include< vector>，不需要\#include< list>等。这允许客户只对它们所用的那一小部分系统形成编译相依。以这种方式切割功能并不适用于类成员函数，因为每一个类必须整体定义，不能被分割为片片段段。

将所有便利函数放在多个头文件但隶属于同一命名空间，意味着客户可以轻松扩展这一组便利函数：只需要添加更多non-member non-friend函数到此命名空间即可

# 总结 #

以non-member、non-friend替换member函数，可以增加封装性、包裹弹性和机能扩充性