分享
 
 
 

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

王朝c/c++·作者佚名  2008-06-01
窄屏简体版  字體: |||超大  

想象一个象征 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

} // functions

...

注重这里就像标准 C++ 库组织得一样严密。胜于有一个单独的一体式的 <C++StandardLibrary> 头文件包含 std namespace 中的所有东西,它们在许多头文件中(例如,<vector>,<algorithm>,<memory>,等等),每一个都声明了 std 中的一些机能。仅仅需要 vector 相关机能的客户不需要 #include <memory>,不用 list 的客户没有必要 #include <list>。这就答应客户在编译时仅仅依靠他们实际使用的那部分系统。当机能来自一个类的成员函数时,用这种方法分割它是不可能的,因为一个类必须作为一个整体来定义,它不能四分五裂。

将所有方便性函数放入多个头文件中——但是在一个 namespace 中——也意味着客户能轻易地扩充方便性函数的集合。他们必须做的全部就是在 namespace 中加入更多的非成员非友元函数。例如,假如一个 WebBrowser 的客户决定写一个关于下载图像的方便性函数,他或她仅仅需要新建一个头文件,包含那些函数在 WebBrowserStuff namespace 中的声明。这个新的函数现在就像其它方便性函数一样可用并被集成。这是类不能提供的另一个特性,因为类定义对于客户是扩充封闭的。当然,客户可以派生新类,但是派生类不能访问基类中被封装的(也就是说,private 的)成员,所以这样的“扩充机能”只有二等身份。此外,不是所有的类都是作为基类设计的。

Things to Remember

·用非成员非友元函数取代成员函数。这样做可以提高封装性,包装弹性,和机能扩充性。

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有