我应该在什么时候喜欢非成员非朋友函数到成员函数? [英] When should I prefer non-member non-friend functions to member functions?

查看:158
本文介绍了我应该在什么时候喜欢非成员非朋友函数到成员函数?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述



例如:

  //网络浏览器允许清除某些东西
class WebBrowser {
public:
...
void clearCache();
void clearHistory();
void removeCookies();
...
};

许多用户都想一起执行所有这些操作,因此 WebBrowser 也可能提供一个函数来做:

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

另一种方法是定义非成员非朋友函数。

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

非成员函数更好,因为



clearBrowser 是方便功能,因为他们无法提供任何功能客户端 客户端不能以其他方式。例如,如果 clearBrowser 不存在,客户端可以调用 clearCache clearHistory removeCookies 本身。



是合理的。但是当非成员版本优秀时,除了方便功能还有什么例子吗?



更广泛地说,什么时候使用的规则是什么?


$

b
$ b

这是Scott Meyer的规则(来源):


Scott有一篇有趣的文章,主张
非成员非朋友函数改进类的封装
。他使用以下算法确定
,其中放置了函数f:

  if(f需要是虚拟的) 
make fa的成员函数;
else if(f是operator>>或operator<<<)
{
make f非成员函数;
if(f需要访​​问C的非公开成员)
make f是C的朋友;
}
else if(f需要在其最左边的参数上进行类型转换)
{
make f非成员函数;
if(f需要访​​问C的非公开成员)
make f是C的朋友;
}
else if(f可以通过C的公共接口实现)
make f非成员函数;
else
make f是C的成员函数;

他的封装定义涉及私人数据$ b时受影响的函数的数量
$ b的会员已更改。


这几乎总算一切,这是相当合理的,在我看来。 / p>

Meyers mentioned in his book Effective C++ that in certain scenarios non-member non-friend functions are better encapsulated than member functions.

Example:

// Web browser allows to clear something
class WebBrowser {
public:
  ...
  void clearCache();
  void clearHistory();
  void removeCookies();
  ...
};

Many users will want to perform all these actions together, so WebBrowser might also offer a function to do just that:

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

The other way is to define a non-member non-friend function.

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

The non-member function is better because "it doesn't increase the number of functions that can access the private parts of the class.", thus leading to better encapsulation.

Functions like clearBrowser are convenience functions because they can't offer any functionality a WebBrowser client couldn't already get in some other way. For example, if clearBrowser didn't exist, clients could just call clearCache, clearHistory, and removeCookies themselves.

To me, the example of convenience functions is reasonable. But is there any example other than convenience function when non-member version excels?

More generally, what are the rules of when to use which?

解决方案

More generally, what are the rules of when to use which?

Here is what Scott Meyer's rules are (source):

Scott has an interesting article in print which advocates that non-member non-friend functions improve encapsulation for classes. He uses the following algorithm to determine where a function f gets placed:

if (f needs to be virtual)
    make f a member function of C;
else if (f is operator>> or operator<<)
{
   make f a non-member function;
   if (f needs access to non-public members of C)
      make f a friend of C;
}
else if (f needs type conversions on its left-most argument)
{
   make f a non-member function;
   if (f needs access to non-public members of C)
      make f a friend of C;
}
else if (f can be implemented via C's public interface)
   make f a non-member function;
else
   make f a member function of C;

His definition of encapsulation involves the number of functions which are impacted when private data members are changed.

Which pretty much sums it all up, and it is quite reasonable as well, in my opinion.

这篇关于我应该在什么时候喜欢非成员非朋友函数到成员函数?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆