Effective c++ 条款23:宁以non-member、non-friend替换member函数

面向对象守则要求数据应该尽可能被封装,member函数带来的封装性比non-member函数低,此外,提供non-member函数可允许对class相关机能有较大的包裹弹性,而那最终导致较低的编译相依度,增加class的可延伸性。因此在许多方面non-member做法比member做法好。

1、越多数据被封装,我们就越能自由地改变对象数据

如果某些东西被封装,它就不再可见,越少人看到它,我们就有越大的弹性去改变它。这就是我们首先推崇封装的原因:它使我们能够改变事物而只影响有限客户。
能够访问private成员变量的函数只有class的member函数加上friend函数而已。如果要你在一个member函数和一个non-member,non-friend函数之间做抉择,而且两者提供相同机能,那么导致较大封装性的是non-member non-friend函数,因为它并不增加“能够访问class之内private成分”的函数数量。这就解释了为什么non-member函数比member和friend函数更受欢迎的原因:它导致class有较大的封装性。
然而这个论述只适用于non-member和non-friend函数,且只因在意封装性而让函数“成为class的non-member”,并不意味它“不可以是另一个class的member”。

2、将所有便利函数放在多个头文件内,它们隶属同一个命名空间

通常大多数客户只对class的某些函数感兴趣,没道理一个只对某些相关便利函数感兴趣的客户与其他便利函数发生编译关系,分离它们最直接的做法就是将某一类相关便利函数声明于一个头文件,而将另一类相关便利函数声明于一个头文件…而这正是c++标准程序库的组织方式。客户也可以轻松扩展这一组便利函数,他们需要做的就是添加更多non-member non-friend函数到此命名空间内。客户只需在该命名空间内建立一个头文件,内含那些函数的声明即可。当然客户也可以派生出新的classes,但derived classes无法访问base class中被封装的成员。于是如此的“扩展机能”拥有的只是次级身份。

猜你喜欢

转载自blog.csdn.net/unirrrrr/article/details/81264776